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A})  sin  let 

riiis  research  devt'lops  a  iiK'thod  for  measuring  .schedule  effectiveness  hv  deter¬ 
mining  the  amounts  of  enroute  cargo  <lelay  caused  by  a  given  aircraft  mission  scIksI- 
ide.  The  rnetliod  is  designed  to  gt'iierate  iidormation  which  helps  identify  flights 
for  which  different  scheduling  might  d<'crea.s('  overall  cargo  delay  in  the  entire  net¬ 
work,  given  that  all  non-sclK'duling  factors  are  held  constant.  The  research  uses  a 
simplified  twelve-airi)ort  cargo  route  lu'twork  to  test  th('  methodology. 
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A  METHOD  FOR  DETERMINING 
SCHEDULE  DELAY  INFORMATION  IN  A 
CHANNEL  CARGO  ROUTE  NETWORK  SCHEDULE 


/.  Introduction 


tUirkqrou  11(1 

1  li('  Military  Airlift  (’ominarul  (MAF)  of  the  I'nitod  State's  Air  force  delivers 
air  cargo  Set  ween  various  locations  tlirougliout  the  world,  do  accomplish  this  mis- 
"iwi!,  M.\(’  Htt<'m[>ts  to  use  available  aircraft  and  personiK'l  in  the  best  wav  possible. 

I  sing  iid'ormation  about  flight  times  and  historical  elemand  for  cargo  shipment  be¬ 
tween  hx  ations,  a  standard  route  structure  for  cargo  flights  has  bet'U  established. 
This  route'  stiue  tiire’  is  re-ferre'd  to  as  the'  ehannel  carge)  reeute'  system.  This  structure 
alleews  for  elire-e  t  shipment  be'twe'en  heavv-elemand  eh'st  inat  ie)n.^  anel  terr  t  ransshipment 
threiiigh  warehouse'  airperrts  lie'tween  light-de'maml  eh’st  inat  ieens.  1  nfeu  t  unate'ly.  sine 
j)lv  flviiig  eemstant  numbe'rs  of  missiejiis  over  the  .same'  reeiite's  fremi  me)nth  to  me)nth 
mav  iieet  always  yie-ld  the  be'st  allocation  e>f  e  ritical  flight  re'seaure  e's. 

1  eii  fise  al  \e'ar  1!)S!).  M.\(’  elelive'red  d'dO.OOO  tons  of  e  argee  eex’cr  !)d()  e  haime'Is 
e  eeime-ei ing  ST  e'ouut. lie’s  at  a  e  ost  of  ST'itt  mi!!u>n  (yit);  1  1  db).  i'or  the  h.urope'an 
the-<ite-r  .laimary  lf)!H  e)|)e'rat ions.  M.\('  flew  !'(>(»  flights  eui  .'>.T  se'])arate'  missieeiis  tei 
ele'live-r  I  0. 01)0  tons  of  earge)  (IT). 

He'eause  tie'  ameeunt  e>f  eargei  teeimage'  shipp<''l  lee’twe'en  elifh're'iit  lexaliems 
threiughout  the-  weerhl  varie-s  e’\f'ry  month,  I  lie  proee'ss  eel  elcteninining  whieh  route's 
shoidd  be-  use-el.  ;uiel  he)W  many  missions  to  fly  on  e-ae  h  route',  must  be  re’-ae  complishe'el 


(■\ciA  iiKiiit li.  .\IA( '  iiiiist  be  cuiucr Ill'll  not  only  wit ii  tin*  efrcct ive  ut ilizat ion  ol  a\aib 
abli'  jiliysical  rt'soiirci's  (I'.u;.,  inonry  ni'i'ilnl  to  pay  for  aircraft,  tncl  and  availability 
of  .lircri'w  personnel),  but  also  with  its  ability  to  deliver  cargo  in  a  timely  manner. 

1  he  ollii  e  of  Force  .St  riict  m  e  .\  nalx  sis  at  llcadipiarters  .M  A( '  (HQ  M.A(  ’/Xl’\  H  ) 
is  tasked  to  deti'rmine  which,  and  how  many,  missions  must  be  flown  evi'ry  month, 
to  deliver  the  forecasted  cargo  di'inands.  .Analysts  at  HQ  MA(’/XPA'K  developed 
a  com[)uter  tnode!  of  this  chatinel  cargo  ronti'  system,  which  is  tised  to  sitni)lifv  the 
process  of  di'terrnitiitig  etlective  plans  to  utilize  thi'  available  flying  resources.  I  hi' 
complexity  of  the  cotti|)utei'  tnodel  has  increased  over  time  as  the  need  has  arisen  for 
it  to  incorporati'  more  concerns  of  the  retil  system. 

/'(  riiiiiiohifi!/ 

1  !;'•  topic  of  this  research  relers  to  various  terms  for  which  ex|)licit  delitiit  iotis 
may  help  ri'duce  ainliiguity. 

The  ti'ftn  chaiiiiel  just  tnentioned  simply  refers  to  "a  pair  of  basi's  betweeti 
whicli  .\I.A('  must  fly  eithi'r  to  di'livi'r  cargo  or  to  satisfy  a  freipii'iicy  of  visit,  e.g.. 
ati  embassy.  re(|uiretneiit  "  (1).  In  other  words,  a  channel  relers  to  a  t wo-locat ioti 
set  for  which  M.AC  prov  ides  (not  necessarily  direct)  di'livi'ry  service  on  a  ri'gularly 
scheduled  basis. 

file  verb  stop  lefers  to  the  act  of  arriving  at  an  airport,  for  itistance.  an 
airplane  tnight  leave  one  airport  and  stop  at  another  airport  before  returtiing  to  the 
hotiie  base.  .\s  ,i  tioim.  stop  refers  to  the  physical  place  s/opprd  at . 

.An  aircraft  s  home  f)ase  is  the  ait  port  whe’e  t  hi'  aircraft  is  noi  tnallv  housed 
when  not  living.  Aircraft  normally  liegin  and  end  trijis  from  thi'se  local  ions  because 
of  the  availability  of  maintenance  lacilities.  aircrews.  .  al  so  forth. 

,A  route  is  a  description  of  an  aircraft  s  out  ire  jonrni'y  from  de|)arture  oi  the 
home  liase  until  ret  nrti  to  the  home  base.  Oni'  typical  route  might  include  de|)art  ing 
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from  Dover,  flying  across  the  Atlantic  Ocean,  stopping  at  Ramstein,  flying  back  over 
the  ocean,  and  returning  to  Dover. 

A  leg  refers  to  the  tra,vel  between  two  points.  In  the  Dover  to  Ramstein 
e.xample,  the  travel  from  Dover  to  Ramstein  is  the  first  leg,  while  the  return  travel 
is  the  second  leg. 

The  term  mission  associates  a  specific  route  with  a  specific  type  of  aircraft. 

.A  flight  refers  to  one  aircraft  flying  a  mission  at  a  specific  point  in  time.  For 
example,  in  a  given  month  a  particular  mission  might  have  ^o  be  flown  fifteen  times 
Each  one  of  the  fifteen  requirements  would  be  a  flight. 

.An  airplane  is  usually  referred  to  by  tail  number.  A  specific  tail  number 
may  or  may  not  be  associated  with  specific  missions.  One  tail  number  will  most 
likely  be  used  for  multiple  flights  during  a  month. 

Current  Procedure 

fl'he  process  M.AC  uses  for  determining  which  missions  to  fly  for  each  month 
is  essentially  a  two-stage  process  as  depicted  in  Figure  1.1.  The  solid  lines  show  the 
major  relationshii)  between  the  two  stages,  while  the  dotted  lines  indicate  where 
information,  other  than  the  missions  chosen,  is  shared  within  the  model.  HQ 
M.AC/XPYR  must  re-accomplish  this  two-stage  process  every  month,  to  determine 
how  to  deliver  the  foreca.'^ted  cargo  demand  (15). 

In  Stage  1 .  t  he  cargo  forecasts,  along  with  the  .set  of  possible  routes  in  the  .M.AC 
system  and  a  databast-  ot  other  information  (e.g.,  flight  times  between  locations,  ter¬ 
minal  storage  ca|)acities,  crew  rest  retiuirements),  are  used  in  the  formulat  ion  of  a 
linear  int('ger  |)rogram.  Because  of  the  problem’s  large  size,  the  integrality  require¬ 
ment  is  relaxed  to  |)er!nit  solution  through  linear  programming.  The  objective  of 
this  linear  programming  lU'laxation  is  to  minimize  the  costs  of  operating  the  system, 
subject  to  the  restriction  t  hat  all  cargo  be  delivered  (15).  In  other  words,  tlu'  mission 


Figuir  1.1.  I  hr  (  ’unent.  M.AC  Model  Procedures 


set  chosen  should  provide  enough  service  between  all  cargo  origin-destination  (0-D) 
airports  to  deliver  the  forecasted  cargo  (6). 

The  results  of  Stage  1  are  known  to  be  approximations,  since  the  linear  pro¬ 
gramming  results  must  be  integerized  to  allow  HQ  MAC  to  tell  the  subordinate 
operational  units  how  many  complete  missions  must  be  flown  (15).  Even  though 
HQ  MAC/XPYR  does  not  schedule  the  actual  missions,  they  must  ensure  the  mis¬ 
sion  set  provided  to  the  operational  units  can  comply  with  the  “Uniform  Materiel 
Movement  Issue  Priority  System  (UMMIPS)  standards”  (19:iii).  To  ensure  compli¬ 
ance  with  the  UMMIPS  standards,  Stage  2  of  HQ  MAC/XPYR’s  process  verifies  the 
mission  set's  ability  to  deliver  the  estimated  cargo  in  a  timely  manner. 

As  can  be  seen  in  Figure  1.1,  a  schedule  of  aircraft  activity  must  be  created  for 
use  in  Stage  2  to  simulate  the  actual  operations.  This  schedule  might  hav'e  significant 
impact  on  the  results  obtained  from  Stage  2.  For  example,  if  a  bad  schedule  were 
created  and  input  into  Stage;  2.  a  lack  of  adherence  to  the  UMMIPS  standards  might 
result  from  the  schedule  itself  —  leaving  no  way  to  determine  whether  the  mission 
set  is  any  good.  On  the  other  hand,  if  a  good  schedule  is  used  for  input,  the  Stage  2 
results  should  not  be  biased  by  the  schedule  —  allowing  determination  of  the  chosen 
mission  set's  ability  to  adhere  to  the  (IMMIPS  standards  (6). 

d'his  verification  stage,  shown  as  Stage  2  in  Figure  1.1,  provides  a  measure 
of  the  delay  encountered  by  cargo  being  shi|)ped  through  the  MAO  network,  as 
<'X|)ressed  in  (irrrafif  ddaii  jirr  ((injo  /on  shipp<ul  between  each  O-l)  pair.  I'his  delay 
UH'asurement  forms  th<’  basis  for  checking  how  w'ell  the  chosen  mission  set  i)rovides 
timely  delivery  service  for  the  forecasted  cargo  demand. 

Prohlf  rti  I 

Simply  put.  IIQ  M.Af '/.X P5  lUs  current  mission  set  evaluation  process  can 
sulfer  from  the  old  adage  “garbage  in.  garbage  out.”  No  method  currently  exists  to 
determiiH'  whether  a  giv('n  schedule  would  be  “garbage”  or  not.  Sinc<'  the  if'sults 


of  the  entire  model  depend  upon  the  schedule,  the  schedule  impacts  the  validity  of 
Stage  2’s  results. 

For  this  reason,  HQ  MAC/XPYR’s  interests  lie  in  finding  a  way  to  evaluate 
mission  schedules,  once  the  other  cost  factors  (i.e.,  which  and  how  many  flights 
to  fly  on  which  routes,  us'ng  which  type  of  available  aircraft  resources)  have  been 
minimized  in  Stage  1.  HQ  MAC/XPYR  wants  development  of  some  procedure  which 
would  produce  better  schedules  for  use  in  the  simulation  portion  of  the  model  for 
timeliness  evaluation  purposes. 

To  perform  this  schedule  evaluation,  a  determination  must  be  made  about 
how  to  differentiate  good  schedules  from  bad  schedules,  therefore,  the  issue  focuses 
on  the  determination  of  what  information  is  required  for  evaluating  one  schedule 
against  another.  Even  though  the  verification  stage  measures  delay,  questions  persist 
about  the  definition  of  delay,  the  way  to  measure  delay,  and  the  factors  which  cause 
delay.  Resolution  of  these  questions  might  provide  a  way  to  evaluate  schedules 
and  ultimately  produce  better  schedules  for  input  to  Stage  2  of  HQ  MAC/XPYR’s 
process. 

The  MAC  channel  cargo  system  is  an  extremely  large  and  complex  network. 
MAC  operates  hundreds  of  aircargo  terminals  throughout  the  world,  with  literally 
hundreds  of  thousands  of  potential  routes.  The  issues  raised  in  the  preceding  para¬ 
graphs  concerning  how  to  measure  delay  and  how  to  find  the  time-dependent  aspects 
of  a  mission  schedule  wlierc  potential  exists  for  delay  reduction  are  just  as  important 
for  less  complicated  route  .systems. 

Purpose  of  the  Research. 

mac’s  current  mission-determining  process  does  not  i)rovide  information  in 
terms  of  enroiite  delay  for  determining  whether  a  given  schedule  is  better  than  other 
jiossible  schediih's.  d'his  research  uses  a  simplified  route  network  to  rlevelop  a  method 
for  measuring  schedule  elfectivt'uess  by  determining  the  amounts  of  enroute  cargo 
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delay  caused  by  a  given  mission  schedule.  This  method,  if  used,  generates  informa¬ 
tion  which  helps  identify  flights  for  which  different  scheduling  might  decrease  overall 
cargo  delay  in  the  entire  network,  given  that  all  non-scheduling  factors  are  held 
constant. 

To  accomplish  the  purpose  of  this  research,  the  information  generated  by  the 
methodology  must  fulfill  two  existing  needs. 

1.  The  need  to  know  the  travel  history  of  every  piece  of  cargo  while  traveling 
through  a  network,  including  the  pickup  and  dropoff  times  at  each  stop,  as 
well  as  which  flights  the  cargo  travelled  on. 

2.  The  need  to  know  amounts  and  types  of  cargo  on  every  flight  leg.  This  in¬ 
formation  might  help  identify  sensitivity  of  the  system  to  potential  changes  or 
schedule  fluctuation. 

Overview  of  Subetequent  Chapters 

Chapter  II  provides  highlights  of  current  literature  applicable  to  the  area  of 
routing  and  scheduling.  1  he  revi('w  focuses  on  problems  associated  with  the  evalu¬ 
ation  of  delay  experienced  by  cargo  while  being  shipped  through  a  route  network. 

The  method  outlined  for  addressing  the  problem  is  explained  in  Chapter  III. 
d  lie  beginning  of  the  chapter  describes  the  inherent  assumptions  allowing  the  method 
to  focus  specifically  on  the  aspects  of  a  route  .system  dependent  on  the  flight  times 
of  a  schedule,  d'he  chapter  inchuh's  a  description  of  the  procedures  used  to  obtain 
the  desired  information  about  (h'lay  cause<i  by  a  given  monthly  mission  schedule.  Fi¬ 
nally,  the  chapter  describes  the  similarities  and  differences  of  the  proposed  informa¬ 
tion  gathering  method  and  the  proce<lure  utilized  within  M.'XC’s  Stage  2  simulation 
program. 

Chapter  IV  (h’scribes  the  sample  route  system  developed  for  testing  the  pro 
posed  method,  and  the  differences  betwi'en  this  systrun  and  the  larger  M.AC  routt' 


network.  The  results  of  applying  the  proposed  methodology  to  the  sample  route  sys¬ 
tem  are  discussed  in  this  chapter.  Specific  attention  emphasizes  how  the  information 
obtained  might  be  used  to  improve  a  mission  flight  schedule. 

Finally,  Chapter  V  provides  the  researcher’s  conclusions  about  the  issues  ad¬ 
dressed  in  the  study  and  recommendations  for  further  research  and  improvement. 


11.  Literature  Review 


This  chapter  reviews  literature  applicable  to  the  research  problem,  focusing  on 
methods  for  obtaining  information  useful  for  measuring  schedule  effectiveness. 

The  Importance  of  Routing  and  Scheduling 

Scheduling  and  routing  problems  have  caused  great  concern  for  a  long  time. 
Caesar  had  to  decide  in  what  order  to  schedule  the  conquering  of  various  regions. 
Marco  Polo  had  to  figure  out  a  route  to  China.  In  essence,  these  two  historical 
figures  accomplished  tasks  that  are  still  done  today.  Research  focuses  now 

not  just  on  how  to  select  routes  and  make  schedules,  but  also  on  how  to  ac¬ 
complish  these  functions  more  effectively  and  efficiently. 

Solomon  and  Desrosiers  provide  the  following  reasons  for  the  need  to  develop 
methods  for  solving  routing  and  scheduling  problems  in  today’s  environment: 


d'he  effective  and  efficient  management  of  the  distribution  of  goods 
or  services  is  becoming  increasingly  important  in  both  the  private  and 
public  sectors.  A  very  important  segment  of  many  distribution  and  trans¬ 
portation  system  costs  is  associated  with  the  routing  and  scheduling  of 
vehicles. 

Due  to  the  intrinsic  complexity  of  distribution  problems  involving 
routing  components,  the  use  of  mathematical-programming-based  models 
and  algorithms  is  needed  when  analyzing  and  solving  such  problems  to 
])ermit  the  realization  of  cost  reduction  or  profit  improvement.  (21:1) 


With  hundreds  of  flights  providing  cargo  delivery  service  to  hundreds  of  airports 
throughout  the  world  every  month,  MAC’s  system  is  certainly  a  very  important 
l)ublic  sector  distribution  system.  Finding  more  effective  and  efficient  techniques  for 
managing  these  activities  has  the  potential  to  reduce  public  outlays  and  increase 
customer  satisfaction. 


Historically,  scliedulers  repeatedly  performed  this  important,  difficult,  and  of¬ 
ten  time-consuming,  mental  and  manual  task.  HQ  MAC/XPYR,  for  instance,  must 
go  through  the  entire  routing  and  scheduling  process  for  its  entire  fleet  every  month. 
The  age  has  arrived  when  computers  can  assume  the  burden  of  accomplishing  some 
of  the  recurring  process.  The  process  still  involves  people,  and  computer  methods 
must  ensure  several  competing  needs  of  the  process  are  met.  Deal  points  out; 


...  we  found  that  any  approach  to  this  planning  should  involve  the 
development  of  a  tool  that  would  provide  continuity  in  scheduling  opera¬ 
tions,  delivering  schedules  at  a  level  of  quality  equal  to  that  exhibited  by 
those  that  had  been  manually  produced,  as  well  as  a  “package'’for  those 
personnel  newly  assigned  to  this  task.  (8:573) 

Researchers  have  found  it  diflicult  to  establish  all-encompassing  mathematical 
models  for  scheduling  and  routing  because  each  problem  has  unique  characteris¬ 
tics.  Soni<’  six'cilic  |)robh'm,s.  such  as  "bulk-cargo  ship  scheduling"  for  the  lb  S. 
Navy  (r_’:27)  and  "intt'rnal  audit  scheduling”  (10:267-272),  convert  to  matlu'matical 
form.  Classes  of  problems  ('xist.  such  as  the  "vehicle  routing  problem  with  slid¬ 
ing  time  windows"  (11:213  220)  or  the  '‘demand-responsive  transj)ortat ion  system" 
( 1  1:630  638),  for  which  certain  mathematical  forms  yield  a  solution.  Notwithstand¬ 
ing  tliese  research  efforts.  Bodin  points  to  some  problems:  “In  rny  opinion,  many 
of  the  problems  described  in  litt'rat  ure  oversimplify  tlu'  ones  that  occur  in  practice 
(3:571). 

d  he  ex|H'rience  and  resea  nil  of  many  authors  have  result('d  in  solutions  to 
a  number  of  dilfert'iit  scluvluling  probh'ins.  Bodin's  caution.  how('V('r.  ]:)oints  to 
the  difficulty  of  linding  solution  te<hni<|ues  for  specific  problems  lik('  the  M.AC 
probhun.  In  la<  t  ,  soiiu'  research  has  lx  *  ii  concruitrated  simi)l\’  to  d<'t<’rmiii<  inev  1o 
measure  scluxluh'  (dfec  t ixc'iiess. 


Measures  of  Effectiveness 

Petersen  and  Taylor  describe  scheduling  problems  as  having  two  distinct  parts: 
“schedule  evaluation”  and  “schedule  selection”  (17:175).  An  important  aspect  of 
their  description  is  a  basis  upon  which  to  evaluate  or  measure  schedule  performance. 
Just  as  a  college  professor  uses  a  scale  for  assigning  grades  to  student  work,  an 
evaluation  scale  establishes  the  method  for  tying  schedule  evaluation  to  schedule 
selection.  This  measure  of  schedule  effectiveness  must  be  directly  tied  to  the  objective 
of  the  scheduling  problem  at  hand. 

The  objective  of  a  scheduling  problem  typically  relates  some  measure  of  ef- 
lectiveness  or  efficiency  to  the  performance  achieved  by  ordering  activities  ixi  some 
particular  sequence.  This  objective  usually  relates  to  two  types  of  performance 
measures.  One  type  of  measure  focuses  on  the  system’s  ability  to  maximize  use 
of  available  delivery  vehicles  or  to  minimize  the  monetary  cost  of  operating  those 
resources.  The  other  type  of  measure  focuses  on  the  timeliness  with  which  the  mis¬ 
sion  of  shipment  delivery  is  accomplished  (See  (18:70)  and  (2:5)).  .Although  related 
to  each  other,  focvis  on  one  ty])e  of  performance  measure  (at  the  expense  of  the 
other)  can  lead  to  .significantly  different  solution  approaches  for  the  sanre  scheduling 
problem. 

Many  different  interpretations  of  system  usage  or  monetary  cost  exist.  In 
the  “scliool-bus  routing  for  program  scheduling”  problem,  Bookl^itider  and  Edwards 
define  cost  as  the  distance  required  to  accomplish  all  tlie  busing  required  in  the 
schedule  (5:79).  I’resumably,  the  distance  traveled  by  the  buses  translates  directly 
into  purchase,  maintenance  and  fuel  costs.  They  also  note  that  other  researchers 
have  used  "the  total  nurnlier  of  veliicles  required”  (5:81)  as  the  measure  of  monetary 
cost. 

Pritsker  highlights  several  ways  lor  determining  how  well  a  system  operates, 
particularly  through  measures  of  throughput  and  resource  utilization  (18:70).  l'\ir- 
fh('r  extension  of  this  iflea  might  include  opportunity  costs  associated  with  choosing 


one  set  of  activities  or  activity  times  when  another  set  could  have  been  chosen  instead 
( 11:214).  Performance  measurements  like  these  apply  ideally  where  the  problem  ob¬ 
jective  relates  to  finding  a  schedule  which  uses  available  resources  as  much  as  possible 
or  expends  the  least  amount  of  money  to  operate  the  ss  stem. 

When  the  system  performance  measurement  related  to  maximization  of  usage 
or  minimization  of  cost  is  not  key,  the  performance  measurement  related  to  timeliness 
can  become  more  important.  HQ  M.A.C/XPYR’s  scheduling  problem  is  one  where 
problem  emphasis  needa  a  measure  focusing  on  this  time  dependence.  The  objectives 
of  their  linear  programming  formulation  are  the  minimization  of  expense  and  the 
maximization  in  the  use  of  availaljlc  aircraft  (15).  To  minimize  the  delay  caused 
through  flight  scheduling,  the  focus  must  now  address  measurement  of  performance 
with  respect  to  timeliness  (or  customer  satisfaction). 

As  with  the  HQ  M.AC/XPYR  problem,  researchers  have  addressed  similar 
scheduling  problems  using  this  different  interpretation  of  the  performance  objective. 
One  researcher  notes,  “one  of  the  basic  measures  of  service  level  in  air  transportation 
is  schedule  delay”  (22:16).  Cargo  experieiux's  this  schedule  delay  either  while  flying 
from  airport  to  airport  or  while  actually  sitting  on  the  ground  somewhere  waiting 
for  further  transportation.  Although  commonly  mentioned  as  important,  researchers 
have  not  adopted  a  universally-accepted  measurement  scale  for  identifying  or  eval¬ 
uating  this  cargo  delay.  The  literature  is  replete  with  ways  to  measure  factors  like 
latcnrs.s,  tnrdinrss,  and  JJowliuif  (2.  1.  18).  l  eodoiT'  nu'nt  ions  that  the  literature 
[)rovides  various  formulas  for  partT  nIar  fax  tors  (22:16).  riiesx*  formulas  can  provide 
statistics  for  rating  system  |)erformanc<'  in  I ime-dx'pendent  terms. 

must  be  taken  wlu'ii  interpreting  ix'sults  rejrorted  in  the.se  statistical 
tf'rms.  For  instancx'.  although  Baker  suggests  minimizing  nifcni  or  wf  ighted  uiran 
tardiiu'ss  or  Howtime  (2:17  2!)).  the  translation  to  spx'cific  event  or  activity  changes 
to  attain  better  results  may  not  be  achieval>I<>.  When  rx'lving  on  these  averagc'd 
results,  there  might  not  be  a  realistic  way  to  hgurx'  out  how  individual  parts  hav<’ 
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affected  the  overall  system  performance.  A  report  of  average  enroute  cargo  delay 
may  not  help  identify  specific  timing  changes  which  might  result  in  better  flight 
schedules,  for  instance. 

For  this  reason,  some  problems  must  be  approached  with  the  objectives  to 
make  system  performance  better  and  to  fully  capture  the  activities  of  each  individ¬ 
ual  element  of  the  system.  Byong-ffun  and  .Jae-Yeong  state:  “Our  objective  is  ... 
minimum  total  travel  time”  (7:394).  Dobson  and  Karmarkar  “minimize  the  total 
weighted  flow  time”  (9:593).  These  research  teams  do  not  want  to  bias  the  results 
by  the  use  of  statistical  averages.  Measuring  performance  based  on  average  values 
might  overlook  or  downplay  the  importance  of  unusual  occurrences  in  situations 
where  non-uniform  performance  within  the  system  is  common.  With  the  variability 
inherent  in  the  MAC  channel  cargo  route  mod<‘l  -  particularly  resulting  from  mag¬ 
nitude  differences  in  amounts  of  cargo  flowing  between  0-D  pairs  —  the  schedule 
optimization  needs  to  address  the  impact  of  even  the  very  small  subsets  of  cargo 
deiTiand  which  could  easily  get  “lost  in  the  shuffle.” 

fhe  delay  e.xperienc('d  by  cargo  traveding  through  the  MAC  channel  route 
system  can  be  split  into  two  parts,  'l  lu’  first  part  is  the  time  required  before  initial 
placement  on  aircraft  at  the  origin  and  the  time  required  to  unload  the  aircraft 
and  deliver  at  the  destination.  4'h('  other  part,  and  the  focus  of  this  research,  is 
the  time  between  initial  pickuf)  and  final  <lropoff.  The  scale  for  measuring  schedule 
effectiveness  for  tliis  researcli  includes  all  flying  time  and  ground  waiting  time  as 
enroute  cargo  <lelay  (6).  Diu'  to  tlu'  need  to  adhere  to  the  IJMMIPS  standards,  less 
enroute  delay  indicates  a  better  scheduh'  for  the  .M.AC  problem. 

Ohtmuinf]  |•■jfrrlivnlrss  VoIiks. 

A  variety  of  useful  t('clmiques  for  obtaining  better  and/or  optimal  solutions 
to  sclu'diding  |)roblems  are  describerl  in  the  literature  (See  (2,  13,  lb)).  Many  of 
these  leclmi<|ues  attc'uqjt  to  ojitimize  the  valu«‘  of  souk'  objective  function  which 


incorporates  the  effectiveness  measurement  of  scheduling  alternatives.  For  example, 
one  might  wish  to  optimize  a  problem  like  Equation  (2.1). 

min  OfX  + /3i/  (2.1) 

Obviously,  for  a  real  (as  opposed  to  theoretic)  problem,  v^alues  must  be  assigned 
to  the  a  and  ;3  coefficients,  dhese  coefficients  typically  relate  to  the  amount  of 
effect!  veness  associated  with  incorporating  the  different  variables  (i.e..  x  and  y)  in  the 
solut  ion.  Many  of  the  optimization  techniques,  although  useful  for  solving  problems 
like  Equation  (2.1),  provide  little  help  in  determinitig  the  values  of  the  pt-rforinance 
itieasurernent  cof'fficients. 

One  technique  for  supplying  these  values  might  b(‘  direct.  j)hysical  measure¬ 
ment.  1  he  times  at  which  each  piece  of  cargo  are  [)icked  up  and  droi)j)ed  off  while 
(Miroute  could  l)e  recorded  and  translated  directly  to  performaiux*  measurement  co- 
efficic'nts.  d'his  technique  might  be  ideal  for  situations  wlu're  the  |)aths  over  which 
<'argo  will  travel  are  known  with  certainty. 

for  .mac's  problem,  direct,  physical  measurement  may  not  be  i)ossil)le  because 
of  the  complexity  of  the  channel  route  system  -  and  the  flight  schedule  is  an  inherent 
component  of  that  complexity.  The  paths  over  which  cargo  will  travel  depend  upon 
the  availability  of  scheduled  flights  at  given  locations  <ii  specific  points  in  tinu  (6). 
For  example,  if  cargo  would  not  have  to  wait  too  long  on  the  ground,  a  direct  flight 
will  i)rovide  the  most  timely  delivery  to  the  next  stop.  If,  however,  the  wait  woidd 
f)e  too  long,  transshipment  using  iiulirect  means  might  he  quickc'r. 

These  time-path  relationships  in  MAC's  prol)lem  make  it  one  for  which  an 
indirfM't  technique  for  measuring  effectiveness  might  be  useful,  if  the  syst('tn  can 
lu'  ac<'urate!y  modeled.  Fritsker  p/i'ovides  the  following  reasons  why  problems  like 
.M.\("s  are  dillicult  to  model: 
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i  he  modeling  of  complex,  large-scale  systems  is  often  more  diilicult 

than  the  modeling  of  physical  systems  for  the  following  reasons; 

1.  few  fnndamental  laws  are  available; 

2.  mail}'  procedural  elements  are  involved  which  are  diilicult  to  de¬ 
scribe  and  represent; 

d.  pcdicy  inputs  are  required  which  are  hard  to  (piantily; 

1.  random  components  are  significant  (dements;  and 

■).  human  decision  making  is  an  integral  part  of  such  systems  (18:4). 

In  M.\('  s  ( as(\  any  oik^  of  tlu'  five  lavasons  alcove'  could  apjrly.  f'uriher- 
more.  thes('  reasons  could  just  as  easily  be  ti.sed  to  d(‘scrib<>  ])roblems  where  indirect 
lierlormaiK  e  measureiiK'nt  is  particularly  useful  for  uinh'rst anding  system  o])era- 
ii()ii>.  .\(  cording  lo  l’rilsk('r.  "simulation  modeds  are  idcudly  suited  tor  carrying  out 
tlie  problem-soK  ing  approac  h  'f  18:5)  for  these  difficult  probh'ins  Ix'cause  t  h<'  t('ch- 
ni(|ue  allows  "observing  tin'  dynamic  behavior  of  a  moded  by  moving  from  state  lo 
slalc"(  1 ''d'l  as  time  progrc'ssc's. 

Hecause  of  t  he  potc'ut  ial  for  extracting  inforntat  ion  about  the  inttunal  ojH'ral ion 
of  a  mochd.  dc\  cdopmcMit  of  a  siimdation  melhoclology  lor  approac  lung  the  \I.\(' 
"c  hechding  proldc-m  could  pro\ide  u.seful  (hday  iidormatioii  Irom  a  moded  ol  M.\('s 
svslcut.  Sjeec  ilically.  a  simulation  methodology  might  allow  detc'rmination  ol  f(irli 
amount  of  enroutc'  deday  experienceci  wIk'Ii  a  given  llight  sc  hedule  is  usc'cl.  Once 
I  ic'i  lot  inane  c  -  cdfect  i\'eness  in  form. »t  ion  is  obtaiiK'ci  about  t  In'  M.\( '  systcmi.  some  ot  her 
tc'i  hin<iue  might  use  that  information  for  sc  Itc'ciuh' cnaluat ion  and  lor  generation  or 
''cdec  lion  ol  belter  sc  hc'clules. 

.■>11111  III  (Iff) 

Man\'  researc  hers  ha\'e  spent  great  (dfort  cle\<do|>ing  tec  hni(|ues  to  solve  prol)- 
lems  rcdalc'd  to  the  routing  and  sc  lu'cliding  of  v<dii<  les.  I  his  edfort  continues  bc'causc' 
ol  the'  moiielaiA  cost  o|  dcdi\cMing  cargo  and  lh<'  nec'cl  for  cdln  ieme  y  of  opcsal  ions, 
lo  soK'e  an\  spec  itic  prolclem.  I  hc'  ix'searcli  must  carcdully  maluatc' t  lu'  j)rold('m  and 


determine  how  the  methods  prev  iously  devedoped  can  be  adapted  to  the  situation  at 
hand  —  particularly  methods  for  defining  s\^stem  performance. 

Because  of  the  schedule'  variability  and  the  need  to  re-accomplish  the  sche'duling 
proce'elure  e'very  montli.  the  |ierformance  measurement  technique  must  be  dynamic 
and  flexible.  Finally,  because  the  MAC  timeliness  standards  apply  to  individual 
piece's  eif  cargo,  pe'rformance  me'asuremeuit  has  to  reflect  the  manner  in  which  each 
pie'ce  of  cargo  travels  from  its  [)lace  e>f  origin  to  its  destination. 


HI.  Development  of  the  Methodology 


This  chapter  explains  the  method  proposed  for  gathering  information  which 
might  highlight  where,  within  a  MAC  channel  cargo  schedule,  potential  exists  for 
improved  tiight  scheduling  resulting  in  less  overall  cargo  delay.  The  first  section 
describes  the  assumptions  of  the  method.  The  second  section  provides  a  detailed 
description  of  the  method.  The  last  section  describes  the  similarities  and  differences 
between  the  methodology  of  this  research  and  the  methodology  employed  wiihin 
M.4C’s  current  simulation  program. 

Assum.ptions 

An  important  aspect  for  the  method  development  is  the  relationship  to  the 
current  MAC  computer  channel  route  model.  That  model  is  based  on  certain  decision 
rules  and  assumptions  implicitly  affecting  the  proposed  methodology.  The  computer 
channel  route  model  also  provides  information  and  results  upon  which  proposed 
method  is  based. 

The  linear  programming  relaxation  applied  in  MAC’s  model  determines  which 
of  the  myriad  missions  making  up  the  entire  system  should  be  used  for  a  particular 
month.  Even  though  changes  to  a  mission  schedule  might  conceivably  promulgate 
a.fljustment  to  the  mission  set  selected,  neither  MAC’s  simulation  nor  this  research’s 
methodology  is  intended  to  support  such  changes. 

This  resc-arcli  assumes  a  monthly  schedule  (like  one  provided  from  HQ  M.XC/ 
XPYR’s  scheduling  program)  forms  a  starting  |)oint  from  which  determination  of 
cargo  delay  can  be  bas<’d.  Using  the  mission  schedule  provided  by  a  scheduling 
IM'ogvam,  a  more  detailed  sclu'dule  can  be  built  detailing  each  JUghf  necessary  for 
th(’  system,  d  ins  fletailerl  schedtde  might  then  provide  a  simulation  program  all  the 
information  lu'cessarv  to  all  aircrad,  fltyhfs. 
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As  with  HQ  MAC/XPYR’s  computer  channel  route  model,  decision  rules  es¬ 
tablish  relationships  between  types  of  cargo  and  specific  missions.  When  an  aircraft 
stops  at  a  cargo  unit’s  point  of  origin  and  stops,  later  in  the  route,  at  the  cargo’s  des¬ 
tination,  ensuring  the  cargo  gets  onboard  aircraft  following  this  route  makes  logical 
sense.  Any  model  must  inherently  rely  on  decision  processes  like  this.  Both  models 
attempt  to  mimic  the  human  decision  making  process  integral  to  the  real  system’s 
operation. 

The  estimated  cargo  tonnage  demanded  for  the  0-D  pairs  is  provided  through 
a  computer  file.  (An  example  demand  file  can  be  found  in  Appendix  P.)  Cargo  is 
assumed  to  enter  the  system,  in  one-ton  units,  evenly  throughout  the  month.  All 
cargo  is  generic  with  respect  to  physical  dimension  and  ])riority  needed  for  delivery. 
I'he  order  in  which  cargo  is  taken  out  of  airi)orts  and  placed  onboard  aircraft  follows 
a  First-In,  First-Out  (FTFO)  rule.  Units  of  cargo  flowing  through  the  real  network 
may  not  be  completely  described  by  any  current  model. 

Like  the  M.AC  model,  this  research  assumes  that  loadmaster  activities  are 
included  as  part  of  the  time  required  to  put  cargo  on  or  lake  cargo  off  aircraft. 
I'his  research  makes  no  attempt  to  model  the  (U'cision  logic  by  which  a  loadmaster 
determines  to  handle  certain  units  of  cargo  and  not  others.  Without  a  procedure  for 
directing  loadmasters  to  perform  their  duties  in  a  particular  way,  neither  the  MAC 
model  nor  this  method  can  approximate  the.se  real  decision  juocesses. 

The  metho<l  assumes  that  tlu'  r<'sources  us<‘d  for  caigo  delivery  are  always 
available.  Aircraft  maintenance  allows  airplam's  to  Ix'  n'adv  for  flying  at  scheduled 
departure  times,  .‘\ircralt  fuel  <  an  always  be  obtained.  Ihiough  aircrews  ('xist  for 
flying  all  flights.  .Any  delay  a.ssociated  with  (Misuring  t  hat  these  resources  are  available 
at  the  [)roj)er  time  is  not  included. 

I'Ih'  monthly  (i.e..  720  hour)  .schedule  btx'aks  down  into  discix'te  instants  of 
time.  Uach  ('vent  (e.g..  aircraft  takeoff  or  landing  and  cargo  pickiij)  or  droiioff) 
occurs  at  one  of  t  hes<'  inst  ants  of  tinu'. 
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Both  models  assume  quantifiable  infonnatioii  used  as  input  for  the  simulation 
is  deterministic,  including  cargo  demand  estimates  and  aircraft  flying  and  ground 
activity  times.  This  assumption  obviously  greatly  simplifies  the  actual  system  in  an 
attempt  to  provide  efflcient  solution  to  this  highly  complex  problem. 

The  decision  rules  necessary  to  provide  fundamental  decisions  determining 
which  cargo  can  travel  on  which  missions  can  be  directly  provided  by  the  user, 
d'his  allows  predetermination  of  “common  sense"’  decisions  through  quick  scanning 
of  the  potential  route  system.  The  method  also  allows  the  computer  program  to 
make  determinations  where  no  predetermined  user  decision  has  been  made. 

Because  of  the  method  used  to  describe  cargo  and  flights  for  this  research,  units 
of  cargo  are  assumed  capable  of  reaching  their  destinations  in  no  more  than  eighteen 
stops.  The  current  MAC  model  does  not  rely  on  a  similar  assumption.  However,  for 
the  actual  network,  this  limitation  may  not  be  significant,  as  routes  chosen  appear 
to  allow  complete  cargo  travel  in  less  than  this  number  of  stops. 

In  sum,  the  assumptions  underlying  this  research  take  on  a  variety  of  forms, 
from  philosophical  to  operational,  fl'he  applicabilil v  of  the  methodology’s  develop¬ 
ment  relies  on  whether  these  assumptions  accurately  reflect  the  important  aspects 
of  the  real  situation. 

Development  of  the  Simnlnirov  Model 

Because  this  research  is  int<'nded  to  gain  information  which  might  allow  ad¬ 
justment  of  specific  ///(////.s.  the  iK'ed  e.xisted  to  use  a  schedule  whose  breakdown  is  by 
individual  flight  leg.  'I'lu'  I'OH  TITAN  i)rograms  re|)rodiired  in  Appendices  A,  B,  and 
('  provide  a  mult iple-iTiont h  scliedule  which  specifically  characterizes  each  separate 
flight  for  a  simulation  |)rogram.  'Tin'  fields  of  data  used  to  describe  each  flight  are 
as  follows; 


•  Field  I  Mission  .Number 


•  Field  2-  f^light  Number 

•  Field  3  -  Tail  Number 

•  Field  4  ^  Aircraft  Capacity  (tons) 

•  Field  5  -  Traveling  Direction 

•  Field  6  -  Home  Base 

•  Field  7-  Stop  Number 

•  Field  8  -  Departure  Location  (same  as  home  base) 

•  Repeating  Fields 

~  9, 12, ...,45  Ground  Time  at  Stop  (first  is  flight  departure  time) 

-  10, 13,. ..,46  Flying  Time  to  Next  Stop 

-  / /, /^,...,^7  Next  Stop  Location 

By  fully  utilizing  all  47  fields  available,  each  flight  defined  in  the  schedule  file 
can  fly  twelve  legs  after  departing  the  home  base.  Appendix  Q  shows  an  excerpt  of 
a  flight  schedule  defined  in  this  manner. 

The  Floxv  of  Events.  The  events  through  which  the  delivery  of  cargo  takes 
place  happen  as  a  result  of  aircraft  departures  and  arrivals  at  airports.  Cargo  does 
nothing  in  and  of  itself  -  it  is  acted  upon.  Each  flight  follows  a  general  flow  of  events 
as  shown  in  F'igure  1 . 

A  flight  departing  a  location  allows  cargo  to  be  placed  onboard  when  certain 
conditions  are  met.  First,  space  must  be  available  on  the  plane.  The  plane  must 
travel  in  the  same  general  direction  the  cargo  is  headed.  E.ssentially,  the  simulation 
attenij)ts  to  mimic  the  real  situation  by  asking  the  question:  ‘‘Are  you  going  my 
way?”  When  a  flight  is  traveling  in  the  direction  which  the  cargo  needs  to  go,  the 
cargo  will  be  assigned  to  the  flight.  For  situations  w'here  cargo  needs  to  travel  on 
sp('cific  missions,  the  flight  must  be  one  of  the  required  missions. 


After  filling  up  to  capacity  or  picking  up  all  cargo  waiting  at  the  airport  which 
the  plane  can  ship,  the  aircraft  will  fly  to  the  next  location.  When  the  aircraft  stops 
at  the  next  airport,  three  different  events  can  occur. 

If  the  cargo  has  arrived  at  its  final  destination,  the  cargo  obviously  gets  off  the 
aircraft  at  that  location.  If  the  aircraft’s  mission  continues  in  the  direction  for  which 
the  cargo  is  destined,  the  cargo  remains  on  the  plane.  On  the  other  hand,  when 
arriving  at  a  transshipment  location,  cargo  must  determine  whether  to  stay  on  the 
aircraft  or  not.  Transshipment  decisions  play  a  great  part  in  the  delay  encountered 
by  cargo  enroute  to  their  destinations. 

.At  some  point  during  an  aircraft’s  mis.sion,  the  direction  traveled  by  the  aircraft 
will  reverse  —  reflecting  the  return  to  the  home  base,  for  instance.  Cargo  not 
intending  to  return  in  the  direction  of  origination  will  get  off  when  the  aircraft’s 
direction  no  longer  becomes  conducive  to  delivery.  In  other  instances,  cargo  may 
arrive  at  an  intermediate  transshipment  location  where  another,  more  direct,  mission 
will  take  it  toward  the  destination.  In  these  cases,  the  cargo  will  also  disembark  and 
await  the  appropriate  mission. 

.4fter  waiting  on  the  ground  for  the  period  of  time  required  for  cargo  offloading, 
fuel  onloading,  aircrew  changes,  or  aircrew  rest,  an  aircraft  will  look  for  additional 
cargo  U)  onload  and  contimie  the  flight  sequence  in  the  manner  just  described.  When 
the  flight  completes  the  route  by  returning  to  the  home  base,  all  cargo  onboard  must 
l)e  offlo.aded  to  await  future  shipment  on  another  flight  . 

The  Simulation  Program  Operation.  A  computer  |Mogram  was  developed  which 
simulates  the  operation  of  a  channel  cargo  route  system  using  “the  .simulation  /anguage 
for  alternative  ;uodeling,  SLAM  11"  ( 18:2).  'bhe  ('ssential  flow  of  events  through  which 
the  simulation  operates  is  provided  in  the  SLA.M  code  found  in  Appendix  D.  (k^r- 
tain  aspects  of  this  system  could  not  be  modeled  directly  in  the  SL.4M  II  language. 
However,  as  Pritsker  mentions,  “Siiu'e  .SLA.M  II  is  l-'ORl  R.4N  based,  it  is  a  rela- 
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lively  simple  matter  to  add  new  functions  to  the  language”  (18:429).  Therefore,  the 
researcher  developed  a  FORTRAN  “user-written  insert”  (18:291)  for  these  purposes. 

In  SLAM  II,  “an  entity  is  any  object  ...  which  defines  or  can  alter  the  state 
of  the  system”  and  “can  be  assigned  attribute  values”  (18:98).  For  this  research, 
the  entities  for  the  channel  route  system  are  aircraft  on  specific  flights  and  units  of 
cargo.  Most  information  about  the  aircraft  flights  is  known  before  a  month  begins 
(e.g.,  where  stops  are  made,  how  much  cargo  can  be  carried,  the  time  when  the 
flight  departs  the  home  base).  Similar  information  about  cargo  may  not  be  known 
in  advance.  For  instance,  knowledge  of  the  amount  of  time  a  particular  unit  of  cargo 
will  wait  somewhere  before  being  picked  up  for  the  next  segment  of  its  journey  may 
not  be  available.  This  simulation  finds  out  this  type  of  information. 

Attribute  fields  for  aircraft  and  units  of  cargo  are  different.  The  information 
included  in  the  attribute  fields  applicable  to  aircraft  flights  has  already  been  shown 
in  the  earlier  discussion  of  the  flight  schedule.  A  breakdown  of  the  attribute  fields 
for  rack  unit  of  cargo  follows: 

•  Fielrt  I  -  Mission  To  Get  On  Flag  (0  indicates  any  mission.  -1  indicates  specific 
missions  required) 

•  Field  2--  Origin  Airport 

•  Field  3-  Destination  .Airport 

•  Field  J,  Direction  Headed 

•  I'lrld  5  Flight  Number  Currently  On 

•  Field  (i  Fail  Number  Currently  On 

•  Field  7  Current  Locat  ion 

•  Field  S  Time  Departed  Origin 

•  Repfnting  Fields 
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—  9, 14, ■■■,94  Flight  Taken  to  Next  Stop 

—  10,15,...,95  Tail  Number  Taken  to  Next  Stop 

—  11,16,. ..,96  Next  Stop  Location 

—  12,n,...,97  T\me  Arrive  Next  Stop 

—  75, Time  Departed  Next  Stop 

When  cargo  entities  are  created,  only  a  few  attribute  values  are  assigned.  These 
fields  (e.g.,  2,  3,  4,  and  7)  serve  as  the  minimum  information  necessary  to  start  cargo 
on  their  journeys.  As  each  unit  of  cargo  flows  through  the  system,  each  might 
on  various  aircraft  and  stop  at  various  airports  before  arriving  at  the  intended  desti¬ 
nation.  The  repeating  attribute  fields  are  designed  to  capture  information  providing 
a  log  or  history  of  each  unit  of  cargo’s  entire  journey.  The  information  describing 
each  successive  leg  is  filled  in  as  the  journey  progresses. 


The  SL.AM  Code.  The  computer  instructions  needed  to  operate  the  simula¬ 
tion  are  reproduced  in  Appendix  D.  Many  of  these  computer  instructions  appear 
redundant,  because  of  the  need  to  create  cargo  for  all  the  different  0-D  pairs.  The 
remainder  of  the  code,  shown  below,  tells  the  simulation  how  aircraft  activities  are 
to  be  performed. 


FILL  EVENT, 1,1;  update  cargo  already  onboard  for  next  leg 
PNEW  EVENT,2,1;  pickup  new  cargo  for  next  leg 
FLY  ACT/2  ,USEFIF(2)  , ;  fly  aircraft  on  next  leg 

ASSIGN,  ATRIB(7)=ATRIB(7)+1 . ;  flight  now  at  next  stop 
ACT,0. ,1. , DROP; 

DROP  EVENT,3,1;  cargo  now  told  at  next  location,  drop  at  final 
destinations 

FDIR  EVENT,4,1;  change  direction  of  aircraft  when  required 
CDIR  EVENT,5,1;  change  cargo  direction  euid  which  missions  allowed 
DOFF  EVENT,6,1;  drop  cargo  at  transshipment  points  when  required 
FFIN  EVENT,7,1;  drop  all  cargo  when  aircraft  route  complete 
GOON/1; 

SIT  ACT/3, USERF(4) ,USERF(3) .NE.ATRIB(6), FILL;  sit  on  ground 
LAST  ACT/4, 0, USERF(3) .EQ.ATRIB(6) ;  at  last  stop 
TERM; 


DONE  QUEUE(21) ,0, ; 

ACT(1).0.,1..; 

CARG  EVENT, 8,1;  information  gathering  for  output 

TERM; 

This  computer  code  implements  the  activities  shown  in  Figure  3.2.  The  solid 
lines  in  Figure  3.2  represent  the  flow  of  activities  happening  to  the  flight  and  cargo 
entities  directly.  For  example,  the  simulation  will  the  planes  or  “sit”  them  on 
the  ground.  The  dashed  lines  indicate  logical  relationships  allowing  actions  carried 
out  indirectly  through  specialized  FORTRAN  code.  A  more  detailed  explanation  of 
the  r'ORTRAN  code  is  provided  in  the  next  section.  What  can  be  seen  from  Figure 
3.2,  however,  is  that  much  of  the  operation  of  the  model  does  not  occur  from  the 
simulation  code  directly,  except  for  the  aircraft  flight  movements  from  airport  to 
airport. 

T  he  boxes  with  the  diagonal  lines  represent  QUEUEs,  or  places  where  the  units 
of  cargo  are  waiting.  The  simulation  establishes  a  computer  file  for  each  QUEUE^ 
where  an  “entity’s  attributes  and  the  relative  position  of  the  entity  with  respect  to 
other  entities  waiting  is  maintained”  (18;116).  The  QUEUEs  in  this  simulation  are 
only  used  for  storing  units  of  cargo.  “FIFO  is  the  default  priority  for  files”  (18:116) 
and  is  used  for  all  QUEUEs  here.  Each  airport  in  the  system  is  represented  by  a 
separate  QUEUE. 

Two  of  the  other  three  QUEUEs  used  in  the  simulation  are  shown  in  Figure  3.2. 
T'he.se  are  the  DONE  and  HOLD  QUEUEs.  All  cargo  arriving  at  their  destinations 
are  |)rocessed  through  the  DONE  QUEUE  for  information  gathering.  The  HOLD 
QUPHH'J  maintains  all  cargo  onboard  all  flights  at  a  particular  point  of  time.  For 
further  discussion  of  these  QUEUEs.  see  Appendix  F. 

Most  of  the  simulation’s  activity  puts  cargo  into  particular  QUEUEs  and  takes 
cargo  out  of  QUEUEs  as  aircraft  “/Zy”  through  the  network.  When  an  aircraft  flight 
entity  passes  through  each  box  of  P'igure  3.2,  such  as  the  PNEW  box,  a  number  of 


Figure  3.2.  SL.^M  Logical  Flow 


3-10 


computer  processes  occur  at  the  FORTRAN  insert  level  of  the  simulation  to  carry 
out  these  cargo  placements. 

The  FORTRAN  insertfi.  The  FORTRAN  code  for  the  simulation  (reproduced 
in  Appendix  E)  provides  for  a  number  of  functions  which  the  particular  simulation 
language  does  not  directly  provide.  The  reason  for  many  of  these  FORTRAN  in¬ 
sert  functions  revolves  around  SLAM’s  inability  to  directly  access  and  change  the 
attribute  values  of  two  different  network  entities  at  the  same  time.  Although  the 
simulation  language  provides  a  way  to  measure  average  cargo  delay,  providing  non- 
averaged  cargo  delay  information  required  the  development  of  FORTRAN  subrou¬ 
tines  specifically  designed  for  this  purpose. 

The  FORTRAN  code  makes  all  the  decisions  shown  in  Figure  3.1  as  the  flights 
follow  the  sequence  of  events  depicted  in  Figure  3.2.  More  importantly,  as  decisions 
are  made  to  assign  cargo  to  specific  flights,  the  FORTRAN  code  inserts  information 
into  the  unfilled  repeating  attribute  fields  for  the  units  of  cargo.  The  information 
placed  in  these  repeating  fields  is  provided  by  the  attributes  of  the  flights  used  and 
the  simulated  time.  One  might  think  of  the  code  as  transferring  flight  attribute 
information  to  cargo  attribute  information  as  the  units  of  cargo  tra^'(‘l  through  the 
system. 

.As  an  example,  consider  the  activities  transpiring  when  a  flight  looks  to  pickup 
new  cargo  at  an  airimrt  (i.e.,  the  PNFW  block  in  Figure  3.2).  The  flight's  attribute 
values  define  the  airport  at  the  flight  is  currently  located.  Once  the  location  is 
determined,  the  FORTU.AN  code  |)eru.ses  the  cargo  waiting  at  that  airport,  looking 
lor  cargo  which  needs  to  travel  in  the  correct  direction  and  on  the  mission  type  to 
vvliich  the  flight  is  assigned  (i.e..  as  depicted  on  the  left  side  of  Figure  3.1).  When 
cargo  is  found  meeting  these  criteria,  the  FORTRAN  code  takes  the  cargo  from  the 
current  air[>ort;  assigns  values  to  the  cargo's  next,  unfilled  .set  of  repeating  attribute 
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fields  (e.g.,  the  flight  taken,  the  time  picked  up,  etc);  and  puts  the  cargo  in  the  cargo 
HOLD. 

Each  activity  block  in  Figure  3.2  (e.g.,  PNEW,  DOFF)  corresponds  to  an  entire 
subroutine  in  the  FORTR.AN  code,  providing  the  computer  instructions  necessary 
to  process  the  decisions  which  must  be  made  as  each  flight  flies  along  its  route.  Two 
other  subroutines  provide  the  cargo  delay  and  flight  leg  utilization  information. 

The  DONE  queue  block  shown  in  Figure  3.2  represents  units  of  cargo  reaching 
their  destinations.  Once  there,  the  FORTRAN  code  essentially  breaks  down  the 
journey  by  each  set  of  repeating  attribute  fields.  Using  this  information  delay  can  be 
measured  from  the  time  each  unit  of  cargo  dep.arted  the  previous  stop  until  departing 
the  present  stop,  fldie  delay-reporting  subroutine  then  groups  similar  cargo  (i.e., 
same  0-1)  pair,  put  onboard  the  same  plane,  at  the  same  airport,  at  the  same  time). 
Fnroute  delay  is  calculated  for  each  group,  subtotaled  for  each  0-D  pair  at  each 
airport,  subtotah'd  for  each  0-D  cargo  pair,  and  totaled  for  all  cargo. 

Having  specific  information  about  cargo  delay  does  not  provide  information 
which  might  lead  to  flight  changes  resulting  in  better  schedules.  For  this  reason 
another  subroutine  looks  at  the  cargo  carried  onboard  each  flight  as  each  route  leg 
is  flown.  This  subroutine  reports  grouped  types  of  cargo  carried  (by  0-D  pair  and 
time  put  onboard)  tor  each  flight  leg. 

As  can  easily  be  seen  by  the  dotted  lines  in  Figure  3.2,  the  great  majority  of 
logical  activity  occurring  wit  bin  t  he  simulation  occurs  as  a  result  of  the  pickup  aiul 
dropoff  of  cargo.  All  of  this  activity  occurs  within  the  FOR'rR.AN  portion  of  the 
simulation  code.  For  a  more  detailed  explanation  of  the  computer  instructions  usi'd 
to  carry  out  tlu'se  activities,  see  .Appendix  F. 

(  ’otiipori.^ou  to  th(  MAC  Sirinilalion 

riu'  simulation  userl  in  MAC's  current  channel  cargo  mcxlel  (hereaftc'r  rc'h'iix'cl 
to  as  .mac's  simulation)  and  this  research's  simidation  perform  tin'  same  general 


function  —  computer  simulation  of  cargo  pickup  and  dropoff  by  aircraft  flying  within 
a  route  network.  (I'he  simulations  use  different  simulation  languages,  although  either 
language  might  be  used.)  These  simulations  model  some  aspects  of  the  problem 
similarly,  while  other  aspects  are  treaU'd  differently.  The  significant  entities  modeled 
in  both  simulations  are  aircraft  and  units  of  cargo. 

Both  simulations  characterize  the  entities  which  can  hold  cargo  (e.g.,  aircraft) 
as  having  certain  attributes  which  may  be  different  from  one  entity  to  another  (e.g., 
home  base,  capacity,  etc.).  In  M.4C’s  simulation,  the  important  aircraft  entity  is  a 
tail  number,  while  this  research  focu.ses  on  each  flight.  The  one-ton  units  of  cargo, 
used  in  both  simulations,  attempt  to  travel  from  their  origin  points  to  their  desti¬ 
nation  points  along  the  most  direct  paths  through  the  system  using  decision  rules 
provided  by  the  simulation  usc'r. 

The  manner  in  which  the  two  simulations  depict  the  entity  characteristics  varies 
considerably.  Both  methods  rely  on  certain  attributes  which  never  change  (e.g.. 
aircraft  capacity  and  cargo  0-1)  pair  information)  and  some  attributes  whose  values 
ihange  as  the  entities  move  throughout  the  system.  The  difference  in  attributes 
relates  to  the  number  of  attributes  reepured  to  describe  an  (uitity  and  to  the  necessity 
for  changing  the  attril)ut(‘  values  at  different  points  in  the  simulation. 

The  entity  attributes  u.sr-d  in  .MAC'S  simidation  focus  forward  in  time.  .\o 
information  is  maintaiiK'd  with  either  aircralt  or  cargo  to  describe'  the  path  use'd 
to  arrive  at  a  particidar  loealnen.  Instead,  the  attributes  supply  inlormation  used 
for  d('termining  how  travel  might  be  accom|)lishe<l  from  the  current  K)cation  in  the 
future.  In  particular,  as  a  unit  of  cargo  travels  through  tin'  system,  minimum  infor 
mation  must  be  maintained  to  adeepiately  d<'scril)e  that  unit  of  cargo  with  respe'ct 
to  where  it  must  go  from  the  curn'ut  location. 

riiis  rese'arch's  simulation,  on  the  ot  In’i'  hainl.  n'lies  \ipon  a  much  large'r  number 
of  attribute's,  fhe'se’  attribute's  supply  ne)t  endy  the  characteristics  apivlie  able'  tee  the 
entity's  current  leee  ation  anel  euie'nt at ieni  within  the  system,  but  also  the  infeuinat ietn 


de-scribing  the  entity’s  entire  travel  history.  In  this  ix'search's  simulation  one  specific 
entity  can  be  fully  described  only  by  all  information  df'scribing  its  entire  path  through 
t  he  system. 

1  he  simulations  rely  on  us('r-provide<l  criteria  through  which  decisions  assign 
cargo  to  aircraft  for  shipment.  Both  simulations  rely  upon  a  two-level  decision¬ 
making  framework.  As  previously  discus.sed,  this  r<'search's  framework  involves  the 
cargo’s  direction  of  travel  and  available  missions  traveling  toward  the  destination 
airport.  MAC’s  simulation  performs  essentially  the  same  operation  in  a  slightly 
diflerent  manner. 

f'or  this  research’s  simulation,  the  u.ser  must  determine  (ahead  of  time)  which 
direction  cargo  must  travel  from  one  location  to  arrive  at  another  location,  and 
wh('ther  assigntmuit  to  particidar  missions  will  allow  more  direct  shipment.  For 
th<‘  MAC  simulation  the  user  must  determine  (ah<'ad  of  time)  which  airport  must 
lx-  visited  after  the  current  airport,,  and  whether  assignment  to  particular  missions 
will  accotiiplish  this  goal.  Flius.  the  differenc<'  in  the  two  methods  revolves  around 
determimition  ol  direct wii  of  tranl  as  opposed  to  plnc<  to  travel  to. 

Both  methods  used  to  simulate  channel  cargo  rout('  syst('m  operations  simplify 
the  real  world  situation.  N’eitlu'r  simulation  a<idress«'s  the  issue  of  tlu'  stochastic 
nature  of  activity  times,  (d  his  research's  simulation  also  does  not  differentiate  tlu' 
cruising  spee(ls  for  dilfercmt  types  t)f  aircraft,  which  impacts  flying  tiiiu')- 

f  urt  hermore,  both  simulations  carry  out  channel  o|)('rations  as  if  a  month’s 
cargo  demand  and  flight  sclu'dide  continiK'  indefinitrdy  into  tin'  futuix'.  flu'se  two 
sirnplilif  at  ions  directly  affect  the  anuaiuts  ol  cargo  in  the  system  as  the  simulations 
o|)erat('  and  the  amounts  of  tinu’  taken  for  cargo  Id  travel  to  tlu'ir  destinations. 

1  his  research  s  simulation  <loes  not  report  cargo  delay  in  t lu'  same  manner  as 
till'  M.\('  simulation.  Because  the  M.\('  simulation  dcx's  not  k('('p  track  of  tlu'  tinu's 
associatrvl  with  c  argo  arrivals  and  departure's  at  eri  rij  airport  whc'ie  cargo  stwjts.  no 


information  remains  available  to  calculate  the  amount  of  delay  experienced  within 
the  journey  from  the  origin  to  the  destination.  By  maintaining  the  minimum  number 
of  attributes  to  distinguish  pieces  of  cargo,  MAC’s  simulation  can  normally  calculate 
oidy  a  moving  average  delay  for  each  0-D  pair  as  cargo  arrive  at  their  destinations. 
Using  the  much  larger  number  of  attributes,  this  research’s  simulation  reports  every 
instance  of  delay  by  all  cargo,  cross-referenced  to  the  time  at  which  units  of  cargo 
experienced  delay,  to  specific  location,  and  to  the  flight  departing  at  that  time. 
The  time,  location,  and  flight  cross-reference  provides  information  for  determining 
where  adjustment  of  the  monthly  flight  schedule  might  result  in  improvement  — 
information  not  available  from  MAC’s  simulation. 

Summary 

This  chapter  has  provided  a  description  of  the  logic  used  to  develop  the  com¬ 
puter  programming  instructions  necessary  to  simulate  the  operation  of  a  channel 
cargo  route  system.  .Assumptions  were  presented  which  focuses  the  simulation’s 
results  on  obtaining  information  specific  to  the  purpose  of  this  research.  The  FOR- 
'I'KAN  programs  and  SLAM  simulation  model  developed  for  this  re.search  depict  the 
activities  transpiring  as  aircraft  flights  pick  up  and  drop  off  units  of  cargo. 

Neither  MAC’s  simulation  nor  this  research’s  simulation  accounts  for  all  fac¬ 
tors  affecting  the  operation  of  MAC’s  channel  cargo  route  system.  Both,  however, 
simidate  net  work  operations  by  allowing  a  method  for  apj)lication  of  user-supplied 
d(  V  ision  rules  for  putting  enroute  cargo  unboard  aircraft  to  provide  delivery  service 
to  the  intended  destinations,  d'hese  two  simulations  are  similar,  except  for  what  de¬ 
cision  criteria  are  re<iuired  and  what  information  is  maintained  to  describe  aircraft 
and  units  of  cargo  as  they  flow  through  a  channel  route  network.  This  difference 
in  information  maintained,  particularly  about  cargo,  forms  the  reason  wdiy  the  two 
simulations  report  cargo  delay  differently. 
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IV.  Methodology  Testing  And  Analysis 


To  show  the  results  obtainable,  this  research  developed  a  hypothetical  channel 
cargo  route  system.  This  chapter  provides  the  information  describing  this  twelve- 
airport  network  and  the  results  obtained  when  using  this  research’s  information¬ 
gathering  methodology  on  the  operations  of  the  hypothetical  system. 

The  Tioelve- Airport  Network 

Based  on  MAC’s  channel  cargo  route  system,  a  hypothetical  twelve-airport 
network  was  developed  with  cargo  demands  occurring  from  a  variety  of  0-D  pairs 
and  with  aircraft  flying  a  number  of  different  missions  to  service  the  cargo  demands. 

By  analyzing  historical  information  provided  by  HQ  MAC/XPYR,  patterns 
of  cargo  demand  were  found  which  impacted  the  choice  of  cargo  tonnage  amounts 
included  in  the  hypothetical  system.  Demand  over  certain  0-D  pairs  is  much  greater 
tliati  (e.g.,  thousands  of  times  larger)  demand  over  other  0-D  pairs.  Because  of  these 
order-of-magnitude  variations,  cargo  demand  for  certain  0-D  pairs  supply  the  bulk  of 
the  cargo  in  the  entire  system.  The  amounts  of  cargo  demanded  in  the  hypothetical 
system  are  shown  in  Table  4.1.  The  computer  file  which  the  simulation  accessed  for 
demand  information  is  reproduced  in  Appendix  P. 

The  amounts  of  demand  shown  in  Table  4.1  are  intended  to  be  representative 
of  the  (h'mand  experienced  in  a  real  channel  cargo  system.  In  this  small  system,  most 
of  the  cargo  demand  is  between  airports  /  and  6.  A  variety  of  demand  levels  exist 
between  other  airports'.  In  fact,  no  demand  was  established  for  airport  11,  which 
represents  a  transshipment  point  only.  And  as  can  be  .seen  in  Table  4.1.  some  0-D 
pairs  have  so  little  demand  as  to  seem  almost  insignificant.  Demand  for  these  0-D 
pairs,  however,  may  prove  to  be  significant  when  the  units  of  cargo  must  compete 
for  aircraft  space  with  the  much  higher  demand  for  other  0-D  pairs. 
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Origin 

■ 

4 

5 

3estina 

6 

tion 

7 

8 

9 

1 

73 

2067 

183 

250 

2 

300 

112 

130 

223 

40 

122 

3 

209 

4 

43 

6 

4 

46 

9 

9 

6 

5 

72 

10 

18 

32 

23 

6 

1161 

62 

27 

183 

11 

7 

47 

28 

32 

8 

145 

9 

50 

35 

9 

61 

12 

21 

10 

29 

8 

9 

4 

11 

12 

240 

52 

15 

Blanks  indicate  no  cargo  demand  between  0-D  pair. 


Table  4.1.  Tons  of  Cargo  Demand  by  0-D  Pair 

Figure  4.1  depicts  the  entire  twelve-airport  system.  The  larger  circles  represent 
the  airports.  The  lines  represent  the  paths  over  which  aircraft  fly,  and  each  route  leg 
is  shown  with  the  mission  number  to  which  it  is  assigned.  All  fourteen  missions  used 
ill  the  small  route  system  are  shown  in  Figure  4.1.  The  different  types  of  lines  provide 
differentiation  between  aircraft  types:  solid  lines  represent  C-5  aircraft,  dashed  lines 
represent  C-141  aircraft,  and  dotted  lines  represent  C-130  aircraft. 

The  distances  between  airport  locations  for  w'hich  cargo  demands  occur  cover 
the  entire  range  of  possible  separations  within  the  network  —  some  0-D  pairs  are 
located  right  next  to  each  other,  some  0-D  pairs  are  at  opposite  ends  of  the  system, 
and  others  are  sonK'wluue  in  between. 

.Aircraft  home  liases  were  chosen  at  only  a  few  of  the  airports  of  the  sj  stem 
since  monetary  and  political  costs  associated  with  housing  maintenance  facilities  and 
aircrew  personnel  at  a  multitude  of  air|)orts  could  be  prohibitive.  In  this  smaller 
system.  ('-.5  and  ('-130  aircraft  are  based  at  airports  /  and  .9,  respectively.  C-141 
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aircraft  are  based  at  two  locations  (i.e.,  airport  2,  and  airport  11  where  transshipment 
facilities  are  available). 

The  routes  in  the  hypothetical  system  were  designed  to  provide  a  system  ex¬ 
hibiting  certain  characteristics.  Because  of  the  need  to  deliver  enormous  quantities 
of  cargo  to  certain  locations,  multiple  routes  might  follow  the  same  path,  although 
not  necessarily  in  the  same  direction.  Certain  routes  follow  an  out-and-back  path 
while  other  route  paths  are  more  circuitous.  Some  routes  allow  for  direct  delivery 
of  heavy-demand  cargo.  Some  routes  selected  for  large  capacity  (e.g.,  C-5)  aircraft 
provide  long-haul  shipment  between  the  major  airports  of  the  system.  These  trunk 
routes  connect  to  local  feeder  routes,  supplying  delivery  service  to  airports  close 
to  the  trunk  route  stops.  In  fact,  certain  route  selections  force  cargo  to  travel  on 
specific  missions  to  depart  and  arrive  at  some  airports.  The  routes  chosen  for  this 
twelve-airport  system  are  provided  in  Appendix  H  and  shown  in  Figure  4.1. 

Additionally,  the  direction  of  travel  along  routes  was  specifically  tailored  to 
provide  as  much  direct  shipment  as  possible  and  to  force  cargo  transshipment  to 
occur  at  a  variety  of  locations  throughout  the  system.  For  example,  in  this  system 
the  majority  of  cargo  demand  occurs  between  airports  1  and  6.  For  this  0-D  pair, 
missions  3  and  .5  allow  for  direct  shipment.  However,  any  cargo  at  airport  2  euroute 
to  airport  5  must  transship  through  another  airport  before  arriving  at  airport  5. 

Along  with  route  selection,  particular  types  of  aircraft  were  assigned  to  each 
route.  In  general,  the  larger  (e.g.,  C-5)  aircraft  were  assigned  to  the  longer  routes, 
although  this  is  not  necessarily  so.  Smaller  (e.g.,  C-130)  aircraft  may  have  longer 
trips,  but  usually  require  extra  stops  along  the  route  for  purposes  of  crew  rest  (t  he 
reason  for  stopping  which  requires  the  longest  ground  time). 

The  jumble  of  lines  interconnecting  the  airports  in  Figure  4.1  might  appear 
confusing.  Any  perceived  confusion  is  inherently  implied  as  a  result  of  the  apparently 
overlapping  routes  used  within  the  system.  Figure  4.1  simply  shows  a  small  exain])le 


4-4 


of  one  of  these  kind  of  networks.  MAC’s  route  system,  with  over  100  airports,  seems 
just  as  confusing. 

The  number  of  flights  for  each  mission  in  the  hypothetical  network  were  cal¬ 
culated  to  approximate  the  number  of  missions  which  would  have  been  selected  by 
the  linear  programming  relaxation  of  MAC’s  computer  channel  route  model.  Par¬ 
ticular  emphasis  was  placed  on  delivering  the  0-D  pair  demand  which  formed  the 
bulk  of  the  total  system  demand.  The  number  of  flights  for  each  mission  can  be 
found  in  Appendix  I.  The  specific  number  of  mission  flights  required  by  this  system 
might  appear  large,  but  this  came  about  simply  from  the  amount  of  cargo  demand 
hypothesized.  MAC’s  system  may  not  have  as  many  of  any  one  type  of  mission,  but 
it  certainly  generates  more  total  flight  requirements. 

Of  particular  concern  in  the  development  of  this  hypothetical  network  was  the 
need  to  incorporate  as  many  aspects  of  MAC’s  system  as  possible.  As  such,  the 
hypothetical  system  operations  may  be  somewhat  dense.  In  other  words,  almost 
anything  that  can  happen  does  happen  —  almost  everywhere.  In  the  larger  MAC 
system,  some  subsets  of  the  system  may  operate  similarly  to  this  hypothetical  case. 
In  other  subsets,  very  little  activity  might  occur.  This  hypothetical  system  thus  may 
not  mimic  .systems  where  there  is  sparse  activity. 

This  small  hypothetical  route  system  exhibits  many  of  the  aspects  of  MAC’s 
channel  cargo  system  including:  (lifferent  types  of  aircraft  flying  on  a  variety  of  mis¬ 
sions;  wide  disparity  in  the  amount  of  cargo  tonnage  demanded  between  0-D  pairs; 
routes,  selected  for  a  variety  of  reasons,  providing  for  direct  shipment  and  trans- 
shi[)ment  of  cargo;  and  most  importantly,  a  system  through  which  cargo  assignment 
decision  rules  allow  for  cargo  to  travel  along  a  variety  of  paths  to  reach  their  intended 
destinations. 

The  com[)lexity  of  the  MAC  computer  channel  route  model  can  be  approxi¬ 
mated  using  a  much  smaller  route  network  (i.e..  one  encompassing  only  twelve  air¬ 
ports).  This  complexity  involves  the  types  of  routes  flown,  the  physical  relationships 


between  the  routes  and  the  0-D  pair  shipments,  and  the  shear  number  of  flights 
required.  The  MAC  model  actually  generates  the  flights  which  are  flown  in  the  real 
system,  whereais  this  research  can  only  approximate  those  results. 

Residts  From  The  Twelve- Airport  System 

The  data  describing  the  hypothetical  cargo  network  (contained  in  Appendices 
G  through  P)  were  processed  by  the  simulation  model  developed  for  this  research.  As 
anticipated,  cargo  delay  was  experienced  throughout  the  system  during  the  month 
of  data  collection  (i.e.,  month  two  of  a  three-month  schedule).  The  subtotal  and 
total  amounts  of  cargo  delay  calculated  for  the  system  are  depicted  in  Table  4.2. 


Destination 

Origin 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

1 

515 

15302 

8406 

44150 

2 

4544 

7270 

13263 

22274 

4106 

3 

2027 

6 

4005 

4 

400 

21 

519 

539 

.5 

2247 

652 

639 

1147 

4628 

6 

17303 

86 

4424 

1275 

298 

7 

4004 

283 

45 

8 

14460 

1607 

3640 

1652 

9 

1677 

940 

238 

10 

11 

12 

1644 

888 

1083 

197 

■ 

7176 

1072 

644 

■ 

Total  Hours  Delay  (All  Cargo) 

Blanks  indicate  no  cargo  demand  between  0-D  pair. 


Table  4.2.  Hours  of  Cargo  Delay  by  0-D  Pair 

As  can  seen  in  Table  4.2,  the  amount  of  delay  applicable  to  different  0-D  pair 
units  of  cargo  varie.s  considerably.  The  figures  in  Table  4.2  are  weighted  by  0-D 
pair,  because  each  unit  of  cargo  carries  the  same  weight  (i.e.,  one  ton)  regardless  of 
whicli  0-D  pair  it  belongs  to.  Direct  comparison  of  these  delay  amounts  might  be 
misinterpreted  if  viewed  without  reference  to  the  number  of  units  flowing  between 
each  pair.  (See  fable  4.1  for  each  0-D  pair  tonnage.) 


Some  of  the  delay  experienced  in  the  twelve-airport  system  highlight  the  pos¬ 
sibility  that  further  investigation  of  simulated  operations  may  be  in  order.  For  in¬ 
stance,  although  the  cargo  tonnage  shipped  each  way  between  airports  1  and  12  are 
nearly  the  same,  Table  4.2  shows  the  amounts  of  delay  associated  with  the  two  0-D 
pairs  to  be  vastly  different.  Another  interesting  result  is  the  cargo  traveling  from 
airport  3  to  airport  10  ~  none  of  it  arrived  during  the  entire  month  of  operations. 
(Although  note  must  be  made  that  this  cargo  accounts  for  only  one-tenth  of  one 
percent  of  the  cargo  flowing  through  the  system.)  This  anomalous  result  may  indi¬ 
cate  the  need  for  further  investigation  into  the  way  simulated  cargo  flows  through 
the  channel  system. 

For  each  subtotal  figure  in  Table  4.2,  the  simulation  provided  information  about 
the  breakdown  showing  where  exactly  the  delay  occurred.  Tables  4.3  and  4.4  show- 
examples  of  this  type  of  breakdown. 


Destination 

Delay  At 

4 

6 

9 

12 

1 

514.80 

15302.33 

4833.55 

4339.30 

3 

886.60 

7016.74 

4 

2580.90 

8163.20 

7 

131.25 

8 

29.05 

9 

20993.16 

10 

2962..30 

11 

105.00 

514.60 

Totals 

514.80 

15302.33 

8406.05 

44149.61 

Blanks  indicates  cargo  did  not  stop  at  location. 


I'able  1.3.  Delay  Hours  Experienced  by  Cargo  Originating  at  .4irport  1 

.As  can  be  seen  from  Table  4.3,  delay  for  .some  0-D  pairs  occurs  at  only  one 
airport  while  delay  for  other  0-D  pairs  occurs  at  a  nunrber  of  airports.  The  fact  that 
cargo  trav<'ling  from  airport  1  to  airport  6  oidy  experiences  delay  associated  with 
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airport  I  is  the  direct  result  of  the  mission  decision  criteria  used  for  the  hypothetical 
route  system.  (As  found  in  Appendix  O,  this  type  of  cargo  was  forced  to  travel 
only  on  direct  missions.)  In  the  case  of  cargo  traveling  from  airport  1  to  airport  12, 
multiple  paths  exist  by  which  cargo  can  (and  did)  make  this  journey.  Thus,  the  last 
column  of  Table  4.3  shows  a  number  of  airports  where  cargo  was  delayed  and  by  how 
many  hours. 

Table  4.4  shows  another  interesting  example  of  the  breakdown  by  location 
where  delay  occurred  at  various  airports.  In  the  case  of  cargo  originating  from 
airport  8,  no  matter  where  cargo  is  destined,  there  are  multiple  paths  over  which 
cargo  traveled. 


Delay  .At 

2 

Destin 

4 

ation 

5 

7 

1 

31.20 

3 

892.40 

527.80 

4 

274.50 

23.80 

5 

3054.30 

621.00 

6 

2561.85 

857.50 

7 

18.55 

4.60 

8 

1247.50 

88.25 

3.37.10 

468.95 

9 

1137.70 

91.75 

56.00 

59.50 

10 

3158.50 

739.50 

1075.50 

1014.10 

ll 

2077.00 

17.20 

757.30 

109.25 

Totals 

14459.85 

1607.45 

3639.60 

1651.80 

Blanks  indicates  cargo  did  not  stop  at  location. 


I'able  l.l.  Delay  Hours  Experienced  by  Cargo  Originating  at  Airport  8 

Information  like  that  shown  in  Tables  4.3  and  4.1  provides  the  data  required  to 
determine  tin-  locations  where  delay  exists  when  the  simulated  net  work  operates.  In 
order  to  mak<'  a  better  schedule  for  the  route  network,  focus  might  then  l)e  directed 
to  decrease  delay  resulting  at  specific  locations.  This  rlelay  might  result  because  of 
a  buildup  of  cargo  awaiting  transportation.  Or,  the  delay  might  simj^ly  result  from 


the  non-availability  of  flights  stopping  at  the  location.  In  any  case,  the  breakdowns 
shown  in  Tables  4.3  and  4.4  do  not  provide  enough  information  to  determine  if  the 
delay  is  significant,  to  assess  whether  schedule  adjustments  will  reduce  the  amounts 
of  delay,  or  to  make  schedule  adjustments  to  individual  flights. 

To  decide  how  modification  of  a  flight  schedule  might  affect  the  simulation  op¬ 
erations  requires  more  detailed  information.  For  this  reason,  the  simulation  provides 
more  detailed  information  than  the  results  shown  in  Tables  4.3  and  4.4. 

Tables  4.5  and  4.6  show  this  type  of  information.  Before  discussing  some  of 
the  implications  of  the  data  in  these  tables,  a  reminder  must  be  made  about  how  the 
information  was  obtained.  .4s  discussed  in  Chapter  III,  the  use  of  cargo  attribute 
values  allows  reconstruction  of  the  flight  paths  of  each  unit  of  cargo  completing  the 
journey  from  origin  to  destination.  The  information  found  in  Tables  4.5  and  4.6 
(and  the  excerpt  of  one  of  the  simulation’s  output  files  found  in  Appendix  R)  is 
based  only  upon  units  of  cargo  which  have  completed  their  journeys  and  have  been 
processed  through  the  last  simulation  event.  This  should  explain  the  references  to 
flights  departing  before  the  beginning  of  the  .second  month. 

I'able  4.5  shows  one  of  many  situations  which  occurred  within  the  twelve- 
airport  route  system.  For  those  34  tons  of  cargo,  which  were  able  to  fly  from  airport 
4  to  airport  5  on  a  direct  flight,  the  only  delay  experienced  was  because  of  the 
flying  time  taken  to  make  the  trip.  1  his  should  not  imply  that  all  the  cargo  going 
from  airport  S  to  airport  5  traveled  through  airport  J/.  But  for  those  that  did.  tlu'v 
experienced  as  little  delay  as  po.ssible  on  that  portion  of  their  journey.  For  situations 
like  that  shown  in  'Table  4.5.  t  he  information  may  not  support  the  need  for  schedule 
adjustment  to  the  as.sociated  flights. 

On  the  other  hand.  Table  4.6  shows  somewhat  different  results.  l'h('  saiiu'  typ(' 
of  cargo  is  the  basis  for  Table  4.6  as  for  Table  4.5  -  cargo  going  from  airport  .s’  to 
airport  5. 
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Tail 

Number 

Flight 

Number 

fbepart 

Time 

Cargo 

Units 

Delay  Hours 
Each  Unit 

Total  Hours 
This  Flight 

15 

183 

733.55 

3 

0.70 

2.10 

15 

202 

793.55 

3 

0.70 

2.10 

15 

212 

853.55 

3 

0.70 

2.10 

15 

229 

913.55 

2 

0.70 

1.40 

15 

246 

973.55 

3 

0.70 

2.10 

15 

262 

1033.55 

1 

0.70 

1.40 

15 

278 

1093.55 

3 

0.70 

2.10 

15 

296 

1 153.55 

3 

0.70 

2.10 

15 

1213.55 

3 

0.70 

2.10 

15 

323 

1273.55 

4 

0.70 

2.80 

15 

341 

1333.55 

3 

0.70 

2.10 

15 

357 

1393.55 

3 

0.70 

2.10 

Subtotal  Delay  23.80 


Transshipinent  At  Airport  4 


Table  4.5.  Delay  Hours  E.xperieueed  by  Cargo  0-D  Pair  8-5 

III  the  instance  ch'picted  in  "Table  4.6.  some  units  of  cargo  apparently  traveled 
on  direct  flights  (as  indicated  by  the  4.75  hours  of  delay  per  unit)  while  other  units 
of  cargo  did  not.  In  particular,  the  two  units  of  cargo  which  were  picked  up  by 
flight  256  experiencerl  a  very  large  amount  of  delay  in  comparison  to  all  the  other 
units  shown.  Tne  obvious  explanation  for  this  delay  is  that  these  units  of  cargo 
appar<’ntly  arrived  at  the  airport  alter  the  other  units  of  cargo  which  were  picked  up 
belor('  them.  Since  the  assignment  of  cargo  to  aircraft  is  assumed  to  follow  a  FIFO 
rule,  these  units  could  not  depart  tlu'  location  until  all  other  units  of  cargo  which 
coidd  tra\'el  onboard  similar  missions  wc're  «'xhauste<l. 

Results  similar  to  that  contained  in  Table  1.6  might  provide  the  information 
iH'cessavy  to  make  sche<hile  ad)\istments.  .\s  an  example,  a  ))otential  adjuslmenl 
might  be  to  push  t h(’  leg  which  flight  256  flies  out  of  airport  6  forward  in  time. 
Anotlu'r  |)ossibility  might  be  to  mo\<' all  flights  prior  to  flight  25(i  forward  in  time, 
to  ch'ar  out  all  cargo  waiting,  lo  make'  any  of  these  adjustments,  howeve’r.  the' 
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Tail 

Number 

Flight 

N  umber 

Depart 

Time 

Cargo 

Units 

Delay  Hours 
Each  Unit 

Total  Hours 
This  Flight 

MSM 

183 

709.95 

1 

4.75 

4.75 

IB 

181 

698.80 

9 

34.75 

69.50 

■M 

202 

769.95 

3 

4.75 

14.25 

15 

212 

829.95 

3 

4.75 

14.25 

15 

229 

889.95 

2 

4.75 

9.50 

15 

246 

949.95 

3 

4.75 

14.25 

15 

262 

1009.95 

1 

4.75 

4.75 

15 

278 

1069.95 

2 

4.75 

9.50 

15 

276 

1058.80 

1 

34.75 

34.75 

15 

296 

1129.95 

3 

4.75 

14.25 

15 

307 

1189.95 

3 

4.75 

14.25 

15 

323 

1249.95 

2 

4.75 

9.50 

15 

256 

986.80 

2 

286.75 

573.50 

15 

341 

1309.95 

3 

4.75 

14.25 

15 

.357 

1369.95 

2 

4.75 

9.50 

14 

351 

1346.80 

1 

46.75 

46.75 

Subtotal  Delay 

857..50 

Transsliipment  At.  .Airport  6 
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rules  to  follow  for  making  schedule  changes  might  need  to  evaluate  the  effects  on  the 
amount  of  cargo  space  utilized  on  aircraft.  The  adjustments  to  any  flight  legs  would, 
most  likely,  be  made  to  the  original  one-month  flight  schedule,  not  the  three-month 
schedule.  (See  Appendices  A,  B,  and  C  for  explanation  of  these  different  schedules.) 
In  the  case  just  mentioned,  flight  256  flying  in  the  second  month  corresponds  to  flight 
Cl  which  began  at  the  same  relative  time  during  the  first  month.  Thus,  an  adjusted 
flight  61  might  form  the  basis  for  a  modified  flight  schedule. 

Table  4.7  displays  the  amount  of  cargo  space  used  on  one  of  the  190  flights  flown 
during  the  second  month  of  simulated  operations.  Table  4.7  also  shows  exactly  wdiich 
type  of  cargo  was  onboard  the  aircraft  during  the  legs  of  the  flight. 

.As  mentioned  in  the  discussion  of  Tables  4.5  and  4.6,  potential  schedule  modi¬ 
fication  might  consider  the  impact  on  aircraft  utilization.  For  example,  if  flight  212’s 
schedule'  was  under  consideration,  the  information  in  Fable  4.7  might  be  useful.  If 
no  other  flight  times  were  to  change,  a  potential  schedule  chang(^  might  involve  de¬ 
laying  the  first  flight  leg  in  order  to  use  more  of  the  aircraft’s  cargo  capacity.  Or, 
otlu'r  flights  might  be  delayed  to  force  more  cargo  onto  flight  2r2’s  first  leg.  With 
the  information  such  as  Table  4.7  available  for  every  flight,  the  process  for  schedule 
adjustment  might  estimate  what  impact  a  change  in  one  flight's  schedule  will  have 
on  other  flights.  Appendix  S  provides  a  small  excery)t  of  the  sinndation’s  report  of 
what  cargo  was  onboard  each  flight  leg. 

4’he  ront<'  structure  and  number  of  flights  used  for  the  hypothetical  twelve- 
airport  route  system  were  designed  to  approximate  the  output  which  would  result 
from  use  of  the  mission  set  provided  by  .\'IA(”s  linear  |)rogramming  re’laxation.  .Al¬ 
though  not  the  purpose  of  this  research,  the  results  showm  in  Fable  4.7  might  jjrovide 
a  ty[)e  of  check  on  a  schedide’s  ability  to  utilize  the  aircraft  space'  available  from  the 
mission  se-t.  One  check  for  a  better  flight  scheelule  might  b('  to  ensure  some  per¬ 
centage  of  flight  legs  are  nearly  fully  loaded  with  cargo.  Caution  may  be  necessary 
witli  this  criteria,  how'ever,  as  com|)letely  lull  flights  may  just  indicate  a  buildup  of 
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Leg 

Origin  Destination 

Cargo 

Time 

Number 

Pair 

Units 

Cot  On 

8  5 

3 

807.50 

1 

8  2 

6 

807.50 

10  1 

2 

807.50 

9  Tons  of  20-Ton  Capacity  Unused 

8  5 

3 

807.50 

8  2 

6 

807.50 

0 

2  5 

3 

829.95 

(j  2 

5 

829.95 

12  5 

1 

829.95 

2  Tons  ot  20- Ton  Capacity  Unused 

8  5 

3 

807.50 

2  5 

3 

829.95 

12  5 

1 

829.95 

2  2  6 

2 

834.70 

2  8 

4 

8.34.70 

2  7 

3 

834.70 

2  12 

2 

8.34.70 

2  10 

2 

834.70 

rOntire  20  Ton-Capacity  Used 

8  5 

3 

807. .50 

2  5 

3 

829.95 

12  5 

1 

829.95 

■1 

2  8 

1 

834.70 

2  7 

2 

824.70 

2  12 

2 

824.70 

2  10 

2 

834.70 

2  5 

2 

852.. 55 

I'ditire  20  Ton-Ca)>acily  Used 

2  8 

1 

821.70 

2  7 

2 

821.70 

2  12 

2 

821.70 

0 

2  10 

2 

.821.70 

5  12 

2 

8.57.. 50 

8 

2 

857. .50 

5  7 

1 

8 5  7. -50 

2  Ions  ol  20  Lon-Capacity 

1  Uiused 

Tail  NuiuIkm'  15  Flying  Mission  Nnintn'r  12 
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cargo  throughout  the  entire  network,  although  the  linear  programming  '-'xation 
procedure  should  account  for  all  anticipated  cargo  demand. 

Summary 

A  small,  hypothetical  version  of  the  MAC  channel  cargo  route  system  devel¬ 
oped  for  this  research  was  explained,  and  shown  to  exhibit  many  of  the  characteristics 
of  the  larger  network  system.  When  used  with  the  information  describing  tu^  hy¬ 
pothetical  network,  the  simulation  generated  information  expected  to  be  useful  for 
analysis  of  the  current  schedule.  The  simulation  results  provided  detailed  explana¬ 
tion  of  which  cargo  experienced  the  enroute  delay  by  O-D  pair.  The  simulation  also 
provided  information  wliich  helps  identify  the  specific  airport  locations  where  the 
cargo  waited  for  aircraft  flights  and  for  which  specific  flights  they  were  waiting.  This 
type  of  information  might  then  be  used  to  determine  how  a  flight  schedule  might  be 
adjusted  for  improved  performance. 


V.  Conclusions  and  Recommendations 


This  chapter  provides  a  summary  of  the  research  and  presents  ideas  for  future 
research  involving  the  use  of  detailed  delay  information  to  improve  the  schedules  in 
the  MAC  computer  cargo  route  model. 

Conclusions 

This  research  has  developed  and  tested  a  method  for  obtaining  the  detailed 
information  necessary  to  identify  enroute  cargo  delay  associated  with  aircraft  de¬ 
partures  within  a  monthly  channel  cargo  route  system  schedule.  The  simulation 
developed  for  this  research  provides  the  output  to  recreate  every  segment  of  every 
unit  of  cargo’s  travel  history  and  identify  all  cargo  traveling  on  all  flight  legs  as  the 
route  system  operations  are  carried  out. 

The  computer  instructions  for  the  simulation  model  perform  a  large  amount 
of  not  only  file  manipulations  but  also  data  searches  and  comparisons.  These  com¬ 
puter  operations  might  require  increased  computer  resources  for  a  larger  channel 
cargo  route  system.  For  the  twelve- airport  system,  the  simulation  took  a  VAX  6420 
computer  5.83  CPU  minutes  to  report  results.  A  correspondingly  more  powerful 
computer  system  may  be  required  to  provide  the  delay  information  for  a  larger  net¬ 
work. 

By  utilizing  information  like  tliat  provided  by  this  research,  determination  can 
be  made  of  where  potential  exists  for  flight  adjustments  resulting  in  enroute  cargo 
delay  reduction.  By  analyzing  the  flight  departures  associated  with  greatest  amount 
of  delay,  changes  to  those  departur<‘>  might  lead  to  the  creation  of  better  schedules. 

Rrronnnendations 

k'uture  research  might  portray  a  mor<'  realistic  model  of  MAC’s  actual  system, 
for  inslarice,  flight  times,  ground  limes,  aiul  cargo  arrival  times  might  be  treated 


stochastically.  Research  could  focus  on  the  manner  in  which  cargo  is  described  within 
the  system  (e.g.,  how  small  should  a  depicted  unit  of  cargo  be,  how  to  assign  cargo  to 
aircraft  where  dimensional  size  is  more  important  than  tonnage,  how  to  describe  the 
prioritization  of  cargo  prior  to  shipping  and  changes  thereto  while  enroute).  Another 
idea  might  be  to  adjust  the  methodology  to  account  for  changes  in  cargo  demand  and 
flight  schedules  w’hich  occur  from  month  to  month.  Therefore,  any  research  which 
decreases  the  assumptions  necessary  to  model  the  system  might  allow  more  realistic 
appraisal  of  the  cargo  delay. 

Future  research  might  focus  on  how  the  decision  criteria  used  for  assigning 
cargo  to  aircraft  flights  affects  the  ability  of  a  schedule  to  decrease  the  enroute  cargo 
delay.  Regardless  of  what  type  of  decision  criteria  are  embedded  in  the  model,  the 
detail  with  which  those  criteria  are  modeled  might  have  significant  implications  on 
the  way  cargo  flows  in  the  network,  waits  for  shipment  at  airports,  and  therefore, 
experiences  delay.  Furthermore,  comparing  the  decision  criteria  used  in  the  model 
against  those  used  in  the  actual  system  would  ensure  that  the  model  provides  a  valid 
portrayal  of  actual  operations. 

As  this  research  measured  delay  ba.sed  on  units  of  cargo  which  had  completed 
their  journeys,  no  information  lias  been  obtained  relating  to  incomplete  journeys. 
Future  research  might  attempt  to  determine  enroute  cargo  delay  for  these  partial 
cargo  journeys. 

1  he  focus  of  this  research  has  been  to  gain  detailed  information  about  en¬ 
route  cargo  delay.  I'he  next  step  in  HQ  .VI A( ’/^'^PTR's  attempt  to  produce  better 
schedules  might  b('  to  develop  a  technique  (e.g..  a  heuristic  procedure)  for  using  this 
information.  To  decide  whether  an  existing  schedule  can  be  improved  upon,  analy¬ 
sis  might  focus  on  aspects  ol  the  schedule  where  modification  would  impact  system 
|)erformance.  Aftr'r  determining  t  he  necessary  adjustments,  the  flight  schedule  could 
be  modified  and  rerun  through  the  simulation  to  assess  delay  associated  with  each 


This  type  of  iterative  procedure  could  be  continued  until  some  degree  of  sched¬ 
ule  goodness  (e.g.,  a  maximum  acceptable  level  of  total  system  delay)  is  attained  for 
the  mission  set. 

Any  schedule  adjustment  procedure  which  might  be  developed  must  address 
the  issue  of  optimality  with  respect  to  the  number  of  aircraft  needed  to  fly  all  the 
flights.  If  adjustments  are  made  to  a  schedule  based  on  a  set  number  of  aircraft, 
the  potential  exists  to  make  changes  which  might  require  more  aircraft  to  fly  all  the 
flights.  If  this  happens,  then  questions  will  have  to  revert  to  which  type  of  system 
performance  measurement  has  priority  —  one  based  on  maximization  of  usage,  or 
minimization  of  (monetary)  cost;  or  one  based  on  the  maximization  of  timeliness,  or 
minimization  of  delay. 

Eiventually  research  might  look  for  a  method  to  measure  schedule  timeliness 
as  the  monthly  mission  structure  is  determined.  The  choice  of  routes  may  implicitly 
impact  a  schedule’s  timeliness,  and  vice  versa.  Therefore,  as  the  mission  set  to 
be  used  for  the  month  is  chosen,  some  measure  of  timeliness  might  help  determine 
whether  one  particular  set  is  better  than  other  sets. 


Appendix  A.  The  CARGRT.FOR  Program 


HQ  MAC/XPYR  has  created  this  FORTRAN  scheduling  program  to  create  a 
schedule  by  which  aircraft  can  fly  their  missions.  This  program  uses  various  data 
(e.g.,  aircraft  flying  times,  aircraft  cargo  capacities,  and  descriptions  of  routes  used), 
stored  in  computer  files,  to  create  a  mission  schedule  shell. 

Examples  and  descriptions  of  the  input  files  used  for  this  program  can  be  found 
in  Appendices  G  through  K.  The  mission  shell  for  all  planes  created  by  the  MAG’s 
FORTRAN  program  is  output  into  computer-file  form  which  can  be  directly  input 
into  their  simulation.  An  example  and  detailed  description  of  this  output  file  is 
provided  in  Appendix  L. 

This  program  for  mission  scheduling  determines  the  minimum  number  of  planes 
which  can  fly  the  number  of  flights  called  for  by  the  linear  programming  relaxation. 
For  each  plane,  the  program  creates  a  shell  by  which  the  plane  will  fly  each  flight  in 
consecutive  sequence.  This  research  uses  MAG’s  program  intact,  with  the  exception 
of  determination  of  each  plane’s  initial  flight  departure  time.  In  the  original  program, 
the  first  plane  begins  its  first  flight  at  the  very  beginning  of  the  month,  while  each 
subsequent  plane’s  first  takeoff  is  delayed  36  hours  from  the  previous  plane’s  first 
takeoff.  For  this  research  the  delay  between  first  departures  has  been  cut  to  2.5 
hours,  allowing  the  program  to  schedule  the  a[)propriate  number  of  flights  called  for 
by  the  linear  programming  output. 

c  This  is  the  SCHEDULE  BUILDING  FORTRAN  program! 

c**  This  program  builds  the  route.dat  and  jet.dat  files 

c**  necessary  for  running  the  chauinel  cargo  simulation  model 
c**  located  on  the  SUN  workstation.  The  program  takes  5  files, 
c**  a  standard  XPYR  formatted  route  file  called  route. inp,  a 


c**  second  file  with  the  corresponding  route  frequencies  called 
c**  freq.inp,  a  base  file  called  base.inp  which  is  a  standard 
c**  location  key.  a  groundtime  file  called  gndtm.inp  and  a 
c**  flying  time  file  called  fly.dat 

c**  This  prograim  was  written  by  HQ  MAC/XPYR  personnel. 

*** 

integer  maxrts  .maxstops  .maixbases 

paraimeter  (maxrts=500  ,maxstops=20  ,maxbases=200) 

integer  nicao(maxrts,majcstops)  ,reason(maxrts .maixstops) 
integer  num.numroutes ,k, i , j ,freq(maxrts) ,actype(maxrts) 
integer  iroute(maxrts .maxstops ,5) ,  numstop(maxrts) 
real  gtm(7,9) ,flytm(maxbases,maxbases) ,route(maxrts .maxstops) 
real  origstart 

integer  a.b.totac.totlines.multac.ace 
character*4  icao(maxbases) 
character*4  name(maxbases) 
character*4  micao(maxrts .maxstops) 

c  *********  Stops  are  input  as  ICAOs.  Reasons  for  ♦♦♦♦******* 

c  *********  stops  are  as  follows: 

c  *********  1)  originate  (start  mission) 
c  *********  2)  onload 

c  *********  3)  offload 

c  *********  4)  enroute  fuel 

c  *********  5)  enroute  crew  change 

c  *********  6)  enroute  crew  rest 

c  *********  7)  spare 

Q  *********  3)  spare 

c  *********  9)  terminate  (stop  mission) 

open (unit=8 ,file= 'base . inp' .status='old' ) 
open(unit=9 .f ile= 'f req. inp’ .status= ’ old ' ) 
open (unit= 10 ,file=’ route , inp’ .status=’old ' ) 
open (unit=l 1 . f ile= ’ route . dat ’ . status= ’ unknown ’ ) 
open(unit=12.f ile=’ jet .dat ’ .status= ’unknown ’ ) 
open(unit=13.f ile=’f ly .dat ’ .status=’ old' ) 
open(unit=14,f ile=’gndtm . inp’ ,status= ’ old ’ ) 

c*******  read  in  ground  times  ************** 
do  50  1=1.7 

read(14,*)  (gtra(i . j ) , j=l .9) 
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50  continue 
close(l4) 


c*******  read  in  base  key  ****************** 
do  98  i=l,maxbases 

read(8,97,end=96)  icao(i) 

98  continue 
97  format (a4) 

96  close(8) 

cj(c**:*i**j(c  read  in  flytimes  ****=(<*Jt‘j|<****i)t!(c+** 
do  60  i=l ,maxbases**2 

read(13,*,end=6l)  a,b ,f lytm(a,b) 

60  continue 

61  close(l3) 

c*******  read  in  routes  ***♦>(<♦******♦**♦♦** 
do  99  i=l,maxrts 

read ( 10 , 101 ,end=100)  (micao(i , j) ,reason(i , j ) , j=l .maxstops) 
do  500  k=l .maxstops 

if  (reason ( i, k) .eq.O)  then 
numstop(i)=k-l 
goto  99 
end  if 

500  continue 

99  continue 

100  close(lO) 

101  format(50(lx,a4,il)) 

numroutes=i-l 
do  80  i=l .numroutes 
do  81  j=l ,numstop(i) 
do  82  k=l,maxbases 

if  (micao(i , j ) . eq. icao(k))  then 
nicao (i , j )=k 
endif 

82  continue 

81  continue 
80  continue 

:4c rsud  iu  route  frequoucies  &  AC  ******** 
c*****  1  =  C005 

2  =  C141 

3  =  C130 

c*=f***  4  =  dC8 
c*****  5  =  DCIO 
<;***♦*  6  =  B747 
c*****  7  =  C17 

do  90  i=l .numroutes 

read(9,*)  f req(i) .actype(i) 
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9C  continue 
close(9) 

c*******  build  route.dat  file  **♦♦♦♦♦**♦*♦♦***♦** 
do  190  i=l,  numroutes 
f lytot=0 
gtmtot=0 
cycle=0 

do  110  j=l,  (numstop(i)-l) 

flytot  =  flytot  +  flytm(nicao(i, j) ,nicao(i, j+1)) 
if  (flytm(nicao(i, j) ,nicao(i, j+1)) .eq.O)  then 
print*,nicao(i, j) .nicaofi.j+l) , '  no  flytime' 
end  if 

gtmtot  =  gtmtot  +  gtm(actype(i) ,reason(i , j ) ) 

110  continue 

cycle  =  flytot  +  gtmtot 
ab  =  cycle  *  freq(i)  /  720.0 
multac  =  int(ab+l) 
turn  =  multac  *  720  /  freq(i) 
endtime  =  turn  -  cycle 
do  120  ace=totac+l,  totac+multac 
if  (ace.eq.totac+1)  then 
startime  =  origstart 
else 

startime  =  startime  +  turn/multac 
end  if 

do  130  1=1  ,nu;flstop(i) 
iroute(ace ,1 , 1)  =  ace 
iroute(ace,l,2)  =  1 
iroute(ace ,1 ,3)  =  nicao(i,l) 
if  (l.eq.l)  then 

route (ace, 1)  =  startime 
elseif  (1 .eq.numstop(i) )  then 
route (ace, 1)  =  endtime 
else 

route(ace,l)  =  gtra(actype(i) ,reason(i,l)) 
endif 

iroute(ace , 1 ,4)  =  i 
iroute(ace,l,5)  =  gtm(actype(i) ,9) 
totlines  =  totlines  +  1 
130  continue 

120  continue 

c**  In  the  original  program  the  2,5  below  was  36. 
origstart  =  origstart  +  2.5 
if  (origstart .gt .336)  then 
origstart  =  1 
endif 

totac  =  totac  +  multac 
190  continue 


c***++**  write  the  jet.dat  file  ****************** 


do  200  i=l,  totac 

write(l2,1000)  i,iroute(i,l,5) 

200  continue 
1000  format (2i4) 

c*******  write  the  route.dat  file  *************** 
do  300  i=l, totac 

do  400  j=l ,numstop(iroute(i , 1 ,4)) 

writeCll ,2000) (iroute(i,j ,k) ,k=l,3) ,route(i,j) ,iroute(i,j ,4) 

400  continue 
300  continue 
2000  format(3i5,f8.2,i5) 

c***  The  print  statement  below  was  added  by  Captain  Moul  at  AFIT. 

print  *,  '  ROUTE.DAT  file  built,  next  step:  run  RAWSCH' 
end 


Appendix  B.  The  RAWSCH.FOR  Program 


The  FORTRAN  program  which  follows  takes  the  mission  schedule  shell  created 
by  the  program  found  in  Appendix  A  and  converts  it  into  the  monthly  flight  schedule. 
This  program  essentially  runs  itself,  after  the  other  program  has  been  run.  The 
FORTRAN  code  follows: 

The  input  files  used  by  HQ  MAC/XPYR’s  FORTRAN  program  supply  nearly 
all  the  data  required  to  create  the  detailed  flight  schedule.  The  files  shown  in  Appen¬ 
dices  .J  and  K  contain  all  information  necessary  to  determine  the  time  needed  during 
each  flight  for  flying  and  for  ground  activities.  By  using  this  data  and  the  time 
at  which  each  tail  number  begins  its  first  flight  (provided  by  HQ  MAC/XPYR’s 
scheduling  program  output),  the  flight  scheduling  program  calculates  the  time  at 
which  each  flight  will  begin  during  a  720-hour  month.  Thus,  except  for  directional 
information,  data  in  a  form  provided  by  current  HQ  MAC/XPYR  files  provides 
everything  necessary  for  defining  each  specific  flight. 

'The  output  file  from  the  program  has  a  number  fields  for  each  flight  into  which 
data  is  stored  to  describe  the  entire  flight  path.  flight  .schedule  itemized  in  tliis 
manner  serves  three  purposes.  First,  a  simulation  program  can  treat  each  flight  as  a 
separate  entity  flowing  through  the  route  system.  Second,  all  information  as.sociated 
with  a  particular  flight’s  stop  at  a  particular  location  can  be  stored  together  with 
a  set  of  fields,  allowing  direct  computer  access  during  simulated  flight.  And  third, 
this  provides  a  file  which  might  be  copied  and  manipulated  by  a  computer  at  some 
later  time  to  reflect  a.  modified  schedule.  Schedule  manipulation  could  then  be 
accomplished  by  individual  flight.  Without  this  detail,  as  currently  output  from 
MAC  s  scheduling  program,  no  rnani|)ulation  of  individual  flights  could  be  directly 
accomplished 

riiough  this  research  is  not  intended  to  delve  into  the  schedule  changes  which 
might  r('sult  in  better  schedules,  schedule  afljnstment  might  need  to  be  made  at  the 
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detailed  level.  For  instance,  if  a  determination  is  made  to  start  a  flight  earlier  in  the 
month  and  then  hold  it  on  the  ground  longer  at  its  first  stop,  the  times  associated 
with  these  activities  could  be  directly  changed  in  that  flight’s  first  two  repeating 
fields.  Chapter  V  provides  further  discussion  of  the  type  of  schedule  adjustment  for 
which  this  level  of  detail  in  a  flight  schedule  might  be  mandatory. 

The  output  file  from  this  flight  scheduling  program  only  provides  a  one-month 
schedule  based  on  the  output  from  MAC’s  mission  scheduling  program.  As  just 
mentioned,  later  manipulation  of  this  output  file  can  be  made.  Furthermore,  flight 
simulation  results  might  be  more  realistic  when  the  flight  schedule  covers  a  longer 
simulated  period  of  flight  operations.  Therefore,  to  allow  conversion  of  a  monthly 
flight  schedule  of  the  form  output  from  this  program  into  a  multiple-month  schedule, 
another  FORTR.^N  program  was  developed. 


c*****  This  is  the  RAWSCH  program,  which  takes  the  R0UTE.DAT  schedule 
c*****  provided  by  the  CARGRT  program,  and  converts  it  to  SRAH1.DAT 
c*****  The  SRAW1.DAT  file  must  then  be  run  through  the  MULTSCH 
program  for  multiple  months  in  schedule. 

This  program  was  written  by  Captain  Moul  at  AFIT. 

COMMON  ISTOP,  MAXBAS,  MAXFLT,  ENDMTH 
DIMENSION  FLYTIM(15,15) ,  SCHED(999 ,47) ,  TEMP(13) 

DIMENSION  FLIGHTS(999) ,  ACTYPE(999) ,  CAP(lO),  FDIRCTf 100 . 14) 

ISTOP  =  47 

MAXFLT  =  999 

MAXBAS  =  15 

ENDMTH  =  719.9999 

OPEN (UNIT= 1 1 , FILE= ' ROUTE . DAT' , STATUS= ' OLD ' ) 

OPEN (UNIT= 12 , FILE= ' FLY . DAT ' , STATUS= ’ OLD ' ) 
0PEN(UNIT=13,FILE=’SRAW1 .DAT' ,STATUS='NEW' ) 

OPEN (UNIT= 14 , FILE= ' FREQ . INP ' , STATUS= ' OLD ' ) 

OPEN (UNIT= 15 , FILE= ' FDIRCT . DAT ' , STATUS= ' OLD ' ) 

OPEN (UNIT= 16 , FILE= ' GNDTM . INP ' , STATUS^ ' OLD ' ) 
open (unit=99 ,file=' out .out ' ,status= 'unknown' ) 

I  =  1 

200  READ(UNIT=14,FMT=*,END=210)  FLIGHTS (I) ,  ACTYPE(I) 

1  =  1  +  1 
GOTO  200 

210  CLOSE (UNIT= 14, STATUS=' KEEP') 

1  =  0 

220  READ(UNIT=15,FMT=’(13F3.0)’ ,END=240)  (TEMP( J) , J=1 , 13) 


n -2 


1  =  1  +  1 
DO  230,  J=l,  13 

FDIRCTd.J)  =  TEMP(J) 

230  CONTINUE 
GOTO  220 

240  CL0SE(UNIT=15.STATUS='KEEP') 

1  =  0 

250  READ(UNIT=16,FMT=*,END=260)  (TEMP( J) , J=1 , 9) 

1  =  1  +  1 
CAP(I)  =  TEMPO) 

GOTO  250 

260  CLOSE (UNIT= 16, ST ATUS=’ KEEP') 

10  READ(UNIT=12,FMT=19,END=20)  ILEAVE,  JARRIV,  FTIME 

19  F0RMAT(I4,I4,F7.2) 

FLYTIMC ILEAVE, JARRIV)  =  FTIME 
GOTO  10 

20  CL0SE(UNIT=12,STATUS='KEEP') 

30  READ(UNIT=11,FMT=39,END=60)  IPLANE,  NUMSTP,  JBASE,  TIME,  MISSON 

39  F0RMAT(I5,I5,I5,F8.2,I5) 

IF(  REAL (IPLANE)  .EQ.  SCHED(IR0W,3)  )  THEN 
c**  here  have  a  matching  plane  number 

IF(  REAL(JBASE)  .EQ.  SCHED(IhOW,6)  )  THEN 
DO  40,  INDEX=11,  ISTOP,  3 
c**  looking  for  the  end  of  a  route. 

IF(  SCHEDCIROW, INDEX)  .EQ.  0.)  THEN 
SCHEDdROW,  INDEX)  =  REAL(JBASE) 

CALL  FLY(SCHED,IROH,FLYTIM) 

CALL  REPEAT (SCHED.IROW, TIME) 

GOTO  30 
END  IF 

40  CONTINUE 
ELSE 

DO  50,  INDEX=11,  ISTOP-3,  3 

IF(  SCHEDCIROW, INDEX)  .EQ.  0.)  THEN 
SCHEDCIROW, INDEX)  =  REAL (JBASE) 

SCHEDCIROW, INDEX+1)  =  TIME 
GOTO  30 
END  IF 

50  CONTINUE 

ENDIF 
ELSE 

C++  here  do  not  have  a  matching  plane  number' 

IROW  =  IROW  +  1 
SCHEDCIROW, 1)  =  REAL (MISSON) 

SCHEDCIROW, 3)  =  REAL (IPLANE) 

SCHEDCIROW, 4)  =  CAP(INT(ACTYPE(MISSON) ) ) 

SCHEDCIROW, 5)  =  FDIRCT(MISSON , 1) 

SCHEDCIROW, 6)  =  REAL( JBASE) 


li  :? 


SCHED(IR0W,7)  =  0. 

SCHED(IR0W,8)  =  REAL(JBASE) 

SCHED(IR0W,9)  =  TIME 
END  IF 
GOTO  30 

60  CLOSE (UNIT=11,STATUS=' KEEP') 

IWROTE  =  0 
TEMPHI  =  -1. 

120  TEMPLO  =  100000. 

DO  130,  1=1,  MAXFLT 

IF(  SCHEDd.l)  .EQ.  0.)  GOTO  130 

IF(  SCHED(I,9)  .LT.  TEMPLO  )  TEMPLO  =  SCHED(I,9) 

IF(  SCHED(I,9)  .GT.  TEMPHI  )  TEMPHI  =  SCHED(I,9) 

130  CONTINUE 

DO  140,  1=1,  IROW 

c+*  Next  if  assigns  flight  numbers,  eliminates  flight  from  further 
c**  consideration,  sends  back  to  find  next  to  tadce  off 
IF(  SCHED(I,9)  .EQ.  TEMPLO  )  THEN 
FLTNUM  =  FLTNUM  +  1. 

SCHED(i,2)  =  FLTNUM 

write (99 ,138)  (sched(i ,kk) ,kk=l , 11) 

WRITE(UNIT=13,FMT=138)  (SCHED(I,KK) ,KK=1,11) 

138  FORMATC'  ' ,F3.0,F4.0,6(F3.0) ,F7.2,F5.2,F3.0) 
WRITE(UNIT=13,FMT=139)  (SCHED(I,KK) ,KK=12,29) 
WRITE(UNIT=13,FMT=139)  (SCHED(I,KK) ,KK=30 , ISTOP) 

139  FORMATC'  ’ , 6 (F5 . 2 ,F5 . 2,F3 . 0) ) 

IWROTE  =  IWROTE  +  1 

IF(  IWROTE  .EQ.  IROW  )  GOTO  150 
SCHED(I,1)  =  0. 

SCHED(I,9)  =  TEMPHI  +  1. 

GOTO  120 
END  IF 

140  CONTINUE 

150  CLOSE (UNIT= 13, STATUS= 'KEEP') 

PRINT  ♦,  '  The  SRAW1.DAT  raw  file  is  complete.' 

PRINT  *,  '  You  can  copy  and  edit  this  file  for  other  flight', 
1 '  schedules . ’ 

PRINT  * 

PRINT  *,  '  You  must  run  MULTSCH  to  make  the  SCHED.DAT  file', 
1'  needed  for  SLAM.' 
close (unit =99 , status= 'keep ' ) 

END 

c**  This  subroutine  fills  in  the  flight  times  from  one  place  to 
c**  another  for  a  row  in  the  schedule 
SUBROUTINE  FLY ( SCHED , IROW , FLYTIM) 

COMMON  ISTOP,  MAXBAS,  MAXFLT 

DIMENSION  SCHED (MAXFLT, ISTOP) ,  FLYTIM(MAXBAS , MAXBAS) 


DO  10,  K=8,  ISTOP-3,  3 


I  =  INK  SCHED(IROW,K)  ) 

J  =  INK  SCHED(IR0W,K+3)  ) 

SCHED(IR0W,K+2)  =  FLYTIM(I,J) 

10  CONTINUE 
20  RETURN 
END 

c**  This  subroutine  creates  new  flights  for  the  schedule,  based  on 
c**  the  TIME  read  in  from  the  last  leg  of  journey. 

SUBROUTINE  REPEAT (SCHED , IRON .TIME) 

COMMON  ISTOP,  MAXBAS,  MAXFLT,  ENDMTH 
DIMENSION  SCHED (MAXFLT. ISTOP) 

TEMP  =  0. 

DO  10,  K=12,  ISTOP-2,  3 

TEMP  =  TEMP  +  SCHED ( IRON, K)  +  SCHED (IR0W,K+1) 

10  CONTINUE 

ADD  =  SCHED (IROW, 10)  +  TEMP  +  TIME 
2C  IF(  (  SCHED (IROW, 9)  +  ADD)  .GT.  ENDMTH  )  GOTO  40 
IROW  =  IROW  +  1 
DO  30,  K=l,  ISTOP 

SCHED ( IROW, K)  =  SCHED ( IROW- 1 ,K) 

30  CONTINUE 

SCHED(IR0W,9)  =  SCHFD(IR0W,9)  +  ADD 
GOTO  20 
40  RETURN 
END 
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Appendix  C.  The  MULTSCH.FOR  FORTRAN  Program 


The  MAC  computer  channel  route  model’s  simulcition  program  results  express 
cargo  delay  for  each  cargo  C-D  pair  that  might  be  realized  if  a  month’s  schedule 
were  in  operation  for  a  period  of  time  longer  than  one  month.  Even  though  the 
average  information  might  obscure  individual  delay-causing  factors,  the  use  of  a 
longer  period  of  time  may  help  obviate  bias  caused  by  model  operation  without  cargo 
iwing  through  the  system  initially.  For  a  similar  reason,  this  research  developed  a 
simulation  relying  on  a  multiple-month  schedule. 

This  separat<=  FORTRAN  program  produces  the  nrmltiple-month  schedule  ac¬ 
tually  used  in  the  simulation  program.  The  program  takes  a  monthly  schedule 
and  add.s  fliglits  to  begin  at  the  same  relative  time,  with  the  same  characteristics, 
in  subseiiuent  months.  Each  subsequent  month’s  flight  schedule  is  a  duplicate  of  the 
first  -  just  delayed  in  time  by  the  appropriate  number  of  hours  (e.g.,  720,  1440, 
et.  .). 

The  [irograin  user  provides  the  number  of  months  the  sclu'diile  will  cover  and 
ili('  nuinber  of  the  schedule  iteration.  This  research  userl  a  three-month  schedule. 
I  he  first  iteration  always  uses  the  initial,  unmodified  schedule  (like  that  created  from 
MAC  s  s(  heduling  program).  Schedules  which  are  modifications  of  that  schedule  can 
still  use  the  multi[)le-moiith  schedule-creation  program  to  generate  flight  schedule 
fur  use  in  simulation. 

I  h('  lOHl  H.A.N  program  that  follows  can  multip’y  any  Jlighf  sclualule  of  the 
lorm  creat('d  by  the  progratn  found  in  Appendix  H.  ddie  user  must  interactively  tell 
the  r(unput<'r  how  many  months  tin*  .schedule'  will  cover,  d'he  us('r  must  also  tell  the 
coni|)uter  which  input  file  will  be  use'd  in  the  next  iteration  of  the  SL.AM  program 
touini  in  ,\i)peiHlices  1)  and  E. 

C  I 


The  first  schedule  iteration  uses  the  schedule  provided  by  the  HQ  MAC/XPYR 
scheduling  program,  after  it  has  been  acted  upon  by  the  RAWSCH  program  (i.e.,  the 
output  SRAW1.DAT  file).  A  user  of  this  proposed  method  might,  after  reviewing 
the  results  obtained  from  the  simulation  program,  decide  to  adjust  the  times  when 
flight  legs  occur.  By  copying  the  SRAW1.DAT  file  and  adjusting  the  times  in  the 
copied  file,  a  new  one-month  schedule  could  be  made.  For  example,  if  simulation 
results  were  desired  with  the  first  flight  commencing  one  hour  into  the  month,  instead 
of  at  the  very  beginning,  a  SRAW2.DAT  could  be  made  from  SRAW1.DAT 
with  this  change.  Then  to  create  the  multiple-month  schedule  for  the  simulation, 
the  MULTSCH  program  will  use  the  SRAW2.DAT  file  when  the  user  tells  the 
computer  program  that  this  is  iteration  2. 

The  output  from  the  MULTSCH  program  is  of  the  exact  same  form  as  the 
SRAVV1.DAT  file  -  just  larger  because  it  covers  more  months.  This  schedule  is 
stored  in  the  SCHED.DAT  file,  which  is  one  of  the  major  input  files  required  to 
run  the  simulation  program  proposed  by  this  research,  d'he  f'CRTRAN  code  follows: 


This  IS  the  MULTSCH  program.  This  program  takes  a  SCH##RAW 
file  and  adds  additional  flights  to  provide  a  multiple-month 
schedule  to  run  the  SLAM  cargo  simulation.  The  output  file 
of  this  program  is  SCHED.DAT,  which  is  used  by  the  SLAM  code. 
This  program  was  written  by  Captain  Moul  at  AFIT. 
c*****  NOTE:  On  first  iteration,  using  MAC'S  CARGRT  program,  through 
c*****  the  RAWSCH  program  the  input  file  would  be  SCH1RAW.DAT  After 
c**:(=**  that,  the  modeler  can  copy  and  edit  the  SCH1RAW.DAT  file  into 
c*:*:***  a  SCH2RAW.DAT,  etc.  Then  SLAM  runs  can  be  accomplished  using 
a  modified  flight  schedule. 

DIMENSION  SCHED(999,47) 

CHARACTER+20  ITER,  TEMP,  FILNAM 
NATFLT  =  47 

PRINT  *,  '  What  SCHED  iteration  is  this  ?  ' 

READ(*, ' (A20) ’)  ITER 
.1  =  LEN(ITER) 

FILNAM  =  'SRAW'  //  ITER(1:J) 

PRINT  * 

PRINT  *,  'How  many  months  to  be  in  schedule  ' 

READ(*, ' (12) ’)  MONTHS 

OPEN (UNIT= 1 1 , FILE=FILNAM , STATUS= ’ OLD ' ) 


0PEN(UNIT=12,FILE=' SCHED . DAT  S  STATUS=  ^  UNKNOWN ' ) 
open(unit=99,f ile='out .out’ ,status=’ unknown’) 

DO  10,  1=1,  999 
IROW  =  IROW  +  1 

READ (UNI T= 1 1 , FMT=8 , END=20)  (SCHED ( I , KK) , KK= 1 , 1 1) 

8  FORMAT(1X,F3.0,F4.0,6(F3.0) ,F7 .2 ,F5 . 2 ,F3 . 0) 

READ (UNIT=1 1 , FMT=9 , END=20)  (SCHED ( I , KK) , KK= 12 , 29 ) 
READ(UNIT=11,FMT=9,END=20)  (SCHED(I,KK) ,KK=30 ,NATFLT) 

9  F0RMAT(1X,6(F5.2,F5.2,F3.0)) 

10  CONTINUE 

20  CLOSE (UNIT=11,STATUS=’ KEEP’) 

IROW  =  IROW  -  1 

C**  Next  set  of  lines  multiply  schedule  by  number  of  months  input. 
C**  Note;  same  flights  in  other  months  will  occur  at  scime  relative 
C**  time  in  month  -  leaving  discontinuity  between  months.. 

DO  30,  1=1,  IROW 

FLTNUM  =  FLTNUM  +  1. 

SCHED (I, 2)  =  FLTNUM 

WRITE(UNIT=12,FMT=28)  (SCHED(I,KK) ,KK=1,11) 

28  FQRMAT(’  ' , F3 . 0 ,F4 . 0 ,6 (F3. 0) ,F7 . 2 ,F5 . 2 ,F3 . 0) 

WRITE ( UN IT= 1 2 , FMT=  29)  ( SCHED ( I , KK ) , KK= 1 2 , 29 ) 
WRITE(UNIT=12,FMT=29)  (SCHED(I ,KK) ,KK=30 ,NATFLT) 

29  F0RMAT('  ’ , 6 (F5 . 2 ,F5 . 2 ,F3 . O) ) 

30  CONTINUE 

DO  50,  M=2,  MONTHS 
DO  40,  1=1,  IROW 

FLTNUM  =  FLTNUM  +  1. 

SCHED (I, 2)  =  FLTNUM 
SCHED(I,9)  =  SCHED(I,9)  +  720. 

WRITE (UNIT= 12, FMT=28)  (SCHED(I,KK) ,KK=l,ll) 

WRITE (UNIT= 12, FMT=29)  (SCHED(I,KK) ,KK=12,29) 
WRITE(UNIT=12,FMT=29)  (SCHED(I,KK) , KK=30 ,NATFLT) 

40  CONTINUE 

50  CONTINUE 
PRINT  ♦ 

PRINT  *,  ’The  SCHED.DAT  file  is  now  ready  for  running  SLAM.' 
PRINT  * 

PRINT  *,  'The  SLAM  and  fortran  codes  are  both  CARGO.' 
CL0SE(UNIT=12 , STATUS= ' KEEP ' ) 
close(unit=99,status='keep' ) 

END 


Appendix  D.  ^  The  CARGO.DAT  SLAM  Code  File 


The  SLAM  code  which  follows  is  all  that  is  necessary  to  run  the  cargo  simu¬ 
lation,  along  with  the  FORTRAN  program  inserts  found  in  Appendix  E.  To  modify 
this  program  the  following  changes  might  need  to  be  made: 


•  LIMITS  -  This  research’s  simulation  is  unusual  because  of  the  requirement 
lo  maintain  attribute  values  for  all  of  these  entities.  For  this  reason,  this 
research  follows  Pritsker’s  advice  of  “the  judicious  use  of  a  safety  factor”  when 
establishing  “the  total  number  of  entities  that  can  exist  in  the  model  at  one 
time”  (18:268). 

•  INIT  -  start  time  and  end  time  in  hours  (time  schedule  covers). 

•  CIlTATTs  -  need  to  set  up  a  CREATE  portion  for  each  0-D  cargo  pair,  with 
mission  flag,  origin,  destination,  direction,  and  current  location,  . 

•  QFEUEs  -  one  uuml^ered  QUEUE  for  each  airport,  renumber  HOLD,  TEMP, 
and  DO.NE  above  the  highest  airport  number. 


GEN , CAPTMOUL , CARGO  DELIVERY , 4/30/92 , 1 , N , N , Y/Y , N , Y/ 1 , 72 ; 

LIMITS, 21 ,98, 10000;  files (queues) , attributes , entities  in  file 
INIT, 0,2 160;  go  three  months,  by  hour 

NETWORK ; 


Clt4  CREATE ,,,,,; 

ASSIGN,  ATRIB(l)=-i. 

ATRIB(4)=5. , 
ACT,USERF(5) , , ; 
GOON/2; 

ACT, , ,Clt4; 

ACT/5, , ,Q001; 

Cite  CREATE, , , ,  ,  ; 

ASSIGN,  ATRIB(1)=-1. 

ATRIB(4)=5. , 
ACT,USERF(5) , , ; 
GOON/2; 

ACT, , ,Clt6; 

ACT/6, , ,Q001; 

Clt9  CREATE, , , , ,  ; 


create  one  lto4  cargo 
,  ATRIB(2)=1.,  ATRIB(3)=4., 
ATRIB(7)=1. , ; 

split  for  next  cargo 

enter  lto4  cargo 
create  one  lto6  cargo 
,  ATRIB(2)=1.,  ATRIB(3)=6., 
ATRIB(7)=1. ; 

split  for  next  cargo 

enter  lto6  cargo 
create  one  lto9  cargo 


1)1 


ASSIGN,  ATRIB(1)=-1.  ,  iiiHiBC2)=l .  ,  AIRIB(3)=9., 
ATRIB(4)=5.,  ATRIB(7)=1.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,Clt9; 

ACT/7 ,, ,Q001 ;  enter  lto9  cargo 

CltW  CREATE, , , , , ;  create  one  ltol2  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=1.,  ATRIB(3)=12. 

ATRIB(4)=5.,  ATRIB(7)=1.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,CltW; 

ACT/8, , ,Q001;  enter  ltol2  cargo 

C2t3  CREATE, , , , , ;  create  one  2to3  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=2.,  ATRIB(3)=3., 
ATRIB(4)=5.,  ATRIB(7)=2.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C2t3; 

ACT/9, , ,Q002;  enter  2to3  cargo 

C2t5  CREATE,,,,,;  create  one  2to5  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=2.,  ATRIB(3)=5., 
ATRIB(4)=5.,  ATRIB(7)=2.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C2t5; 

ACT/10 ,, ,Q002 ;  enter  2to5  cargo 

C2t7  CREATE,,,,,;  create  one  2to7  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=2.,  ATRIB(3)=7., 
ATRIB(4)=5.,  ATRIB(7)=2.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C2t7; 

ACT/11 ,, ,0002 ;  enter  2to7  cargo 

C2t8  CREATE,,,,,;  create  one  2to8  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=2.,  ATRIB(3)=8., 
ATRIB(4)=5.,  ATRIB(7)=2.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C2t8; 

ACT/12,,,0002;  enter  2to8  cargo 

C2t0  CREATE,,,,,;  create  one  2tol0  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=2.,  ATRIB(3)=10. 

ATRIB(4)=5.,  ATRIB(7)=2.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C2tO; 

ACT/13,,,0002;  enter  2tol0  cargo 

C2tW  CREATE,,,,,;  create  one  2tol2  cargo 

ASSIGN,  ATRIB(1)=-1 . ,  ATRIB(2)=2.,  ATRIB(3)=12. 
ATRIB(4)=5.,  ATRIB(7)=2.; 


ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT,,,C2tW; 

ACT/14, , ,Q002;  enter  2tol2  cargo 

C3t2  CREATE,,,,,;  create  one  3to2  cargo 

ASSIGN,  ATRIB(1)=-1.,  ATRIB(2)=3.,  ATRIB(3)=2., 
ATRIB(4)=15.,  ATRIB(7)=3.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , .C3t2; 

ACT/15, , ,Q003;  enter  3to2  cargo 

C3t4  CREATE,,,,,;  create  one  3to4  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=3.,  ATRIB(3)=4. , 
ATRTB (4) =5 . ,  ATRIB (7) =3 . ; 

ACT,USERF(5) ,  , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C3t4; 

ACT/16, , ,Q003;  enter  3to4  cargo 

C3t6  CREATE,,,,,;  create  one  3to6  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=3.,  ATRIB(3)=6., 
ATRIB (4) =5 . ,  ATRIB (7) =3 . ; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C3t6; 

ACT/17 ,, ,Q003 ;  enter  3to6  cargo 

C3t0  CREATE,,,,,;  create  one  3tol0  cargo 

ASSIGN,  ATRIB(1)=-1.,  ATRIB(2)*3.,  ATRIB(3)  =  10 . , 
ATRIB (4) =5.,  ATRIB (7) =3.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C3tO; 

ACT/18, , ,Q003;  enter  3tol0  cargo 

C4tl  CREATE,,,,,;  create  one  4tol  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=4.,  ATRIB(3)=1., 
ATRIB(4)=15. ,  ATRIB(7)=4.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT,,,C4tl; 

ACTA9 ,  ,  ,Q004;  enter  4tol  cargo 

C4t6  CREATE,,,,,;  create  one  4to6  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=4.,  ATRIB(3)=6., 
ATRIB(4)=5.,  ATRIB(7)=4.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C4t6; 

ACT/20, , ,0004;  enter  4to6  cargo 

C4t9  CREATE,,,,,;  create  one  4to9  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=4.,  ATRIB(3)=9., 
ATRIB(4)=5.,  ATRIB(7)=4.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 


ACT, , ,C4t9; 

ACT/21,,, Q004-, 

C4tO  CREATE,,,,,; 

ASSIGN,  ATRIB(1)=0., 
ATRIB(4)=5. , 
ACT,USERF(5), , ; 
GOON/2; 

ACT, , ,C4tO; 

ACT/22, , ,q004; 

C5t2  CREATE, , , , , ; 

ASSIGN,  ATRIB(1)=-1. 

ATRIB(4)=15. 
ACT,USERF(5), , ; 
GOON/2; 

ACT, , ,C5t2; 

ACT/23, , ,Q005; 

C5t4  CREATE,,,,,; 

ASSIGN,  ATRIB(1)=0., 
ATRIB(4)=15. 
ACT,USERF(5) , , ; 
GOON/2; 

ACT,, ,C5t4; 

ACT/24, , ,q005; 

C5t7  CREATE, , ,, , ; 

ASSIGN,  ATRIB(1)=0., 
ATRIB(4)=5. , 
ACT,USERF(5), , ; 
GOON/2; 

ACT, , ,C5t7; 

ACT/25, , ,q005; 

C5t8  CREATE,,,,,; 

ASSIGN,  ATRIB(1)=0., 
ATRIB(4)=5. , 
ACT,USERF(5), , ; 
GOON/2; 

ACT, , ,C5t8; 

ACT/26, ,  ,Q005; 

C5tW  CREATE, , , , , ; 

ASSIGN,  ATRIB(1)=0., 
ATRIB(4)=5. , 
ACT,USERF(5) , ,  ; 
GOON/2; 

ACT,  ,  ,C5tVJ; 

ACT/27,  ,  ,q005; 

C6tl  CREATE, , , , , ; 

ASSIGN,  ATRIB(1)=-1. 

ATRIB(4)=15. 
ACT,USERF(5) , , ; 
GOON/2; 

ACT, , ,C6tl; 

ACT/28, , ,q006; 


enter  4to9  cargo 
create  one  4tol0  cargo 
ATRIB(2)=4.,  ATRIB(3)=10. , 
ATRIB(7)=4. ; 

split  for  next  cargo 

enter  4tol0  cargo 
create  one  5to2  cargo 
,  ATRIB(2)=5.,  ATRIB(3)=2., 
,  ATRIB(7)=5.; 

split  for  next  cargo 


enter  5to2  cargo 
create  one  5to4  cargo 
ATRIB (2) *5 . ,  ATRIB (3) =4 . , 
,  ATRIB(7)=5.; 

split  for  next  cargo 


enter  5to4  cargo 
create  one  5to7  cargo 
ATRIB(2)*5..  ATRIB(3)=7., 
ATRIB (7) *5. ; 

split  for  next  cargo 


enter  5to7  cargo 
create  one  5to8  cargo 
ATRIB (2) =5 . ,  ATRIB (3) =8 . , 
ATRIB (7) =5. ; 

split  for  next  cargo 


enter  5to8  cargo 
create  one  5tl2  cargo 
ATRIB(2)=5.,  ATRIB(3)=12. , 
ATRIB(7)=5. ; 

split  for  next  cargo 

enter  5tol2  cargo 
create  one  6tol  cargo 
,  ATRIB(2)=6.,  ATRIB(3)=1., 
,  ATRIB(7)=6.; 

split  for  next  cargo 


enter  6tol  cargo 


C6t3  CREATE,,,,,;  create  one  6to3  cargo 

ASSIGN,  ATRIB(1)=-1.,  ATRIB(2)=6.,  ATRIB(3)=3. , 
ATRIB(4)=15. ,  ATRIB(7)=6.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C6t3; 

ACT/29, , ,Q006;  enter  6to3  cargo 

C6t4  CREATE,,,,,;  create  one  6xo4  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=6.,  ATRIB(3)=4., 
ATRIB(4)=15. ,  ATRIB(7)=6.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C6t4; 

ACT/30 ,, ,Q006 ;  enter  6to4  cargo 

C6t9  CREATE,,,,,;  create  one  6to9  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=6.,  ATRIB(3)=9. , 
ATRIB(4)=10. ,  ATRIB(7)=6.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C6t9; 

ACT/31 ,, ,Q006 ;  enter  6to9  cargo 

C6t0  CREATE,,,,,;  create  one  6tol0  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=6.,  ATRIB(3)=10 . , 
ATRIB(4)=10. ,  ATRIB(7)=6.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C6tO; 

ACT/32 ,, ,q006 ;  enter  6tol0  cargo 

C7t2  CREATE,,,,,;  create  one  7to2  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=7.,  ATRIB(3)=2., 
ATRIB(4)=10. ,  ATRIB(7)=7.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C7t2; 

ACT/33 ,, ,0007 ;  enter  7to2  cargo 

C7t5  CREATE,,,,,;  create  one  7to5  cargo 

ASSIGN,  ATRIB(1)=-1.,  ATRIB(2)=7.,  ATRIB(3)=5., 
ATRIB(4)=10. ,  ATRIB(7)=7.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C7t5; 

ACT/34, , ,Q007;  enter  7to5  cargo 

C7t8  CREATE,,,,,;  create  one  7to8  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=7.,  ATRIB(3)=8., 
ATRIB(4)=5.,  ATRIB(7)=7.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C7t8; 

ACT/35 ,, ,Q007 ;  enter  7to8  cargo 

C8t2  CREATE,,,,,;  create  one  8to2  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=8. ,  ATRIB(3)=2., 


ATRIB(4)=5.,  ATRIB(7)=8.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C8t2; 

ACT/36, , ,0008;  enter  8to2  cargo 

C8t4  CREATE,,,,,;  create  one  8to4  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=8. ,  ATRIB(3)=4., 
ATRIB(4)=5.,  ATRIB(7)=8.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C8t4; 

ACT/37, , ,Q008;  enter  8to4  cargo 

C8t5  CREATE,,,,,;  create  one  8to5  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=8.,  ATRIB(3)=5., 
ATRIB(4)=5.,  ATRIB(7)=8.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C8t5; 

ACT/38,,,0008;  enter  8to5  cargo 

C8t7  CREATE,,,,,;  create  one  8to7  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=8.,  ATRIB';?)-7 .  , 
ATRIB(4)=5.,  ATRIB(7)=8.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C8t7; 

ACT/39,,,0008;  enter  8to7  cargo 

C9tl  CREATE,,,,,;  create  one  9tol  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=9.,  ATRIB(3)=1., 
ATRIB(4)=15. ,  ATRIB(7)=9.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C9tl ; 

ACT/40,,,0009;  enter  9tol  cargo 

C9t4  CREATE,,,,,;  create  one  9to4  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=9.,  ATRIB(3)=4. , 
ATRIB(4)=10. ,  ATRIB(7)=9.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C9t4; 

ACT/41,,,0009;  enter  9to4  cargo 

C9t6  CREATE,,,,,;  create  one  9to6  cargo 

ASSIGN,  ATRIB(1)=-1. ,  ATRIB(2)=9.,  ATRIB(3)=6., 
ATRIB(4)=10. ,  ATRIB(7)=9.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,C9t6; 

ACT/42,,,0009;  enter  9to6  cargo 

COtl  CREATE,,,,,;  create  one  lOtol  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=10 . ,  ATRIB(3)=1., 
ATRIB(4)=10. ,  ATRIB(7)=10. ; 

ACT,USERF(5) , , ;  split  for  next  cargo 


GOON/2; 

ACT, , ,COtl; 

ACT/43, , ,Q010 ;  enter  lOtol  cargo 

C0t3  CREATE,,,,,;  create  one  10to3  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=10 . .  ATRIB(3)=3., 
ATRIB(4)=10. ,  ATRIB(7)=10.; 


ACT,USERF(5), ,; 
GOON/2; 

ACT, , ,C0t3; 

ACT/44, , ,q010; 

C0t4  CREATE, , , , , ; 

ASSIGN,  ATRIB(1)=0. 

ATRIB(4)=10 

ACT,USERF(5),,; 

GOON/2; 

ACT, , ,C0t4; 

ACT/45, , ,0010; 
cote  CREATE, , , , , ; 

ASSIGN,  ATRIB(1)=0. 

ATRIB(4)=10 
ACT,USERF(5) , , ; 
GOON/2; 

ACT, , ,C0t6; 

ACT/46, , ,0010; 

CWt 1  CREATE ,,,,,; 


split  for  next  cargo 


enter  10to3  cargo 
create  one  10to4  cargo 
ATRIB(2)=10. ,  ATRIB(3)=4., 
,  ATRIB(7)=10. ; 

split  for  next  cargo 


enter  10to4  cargo 
create  one  10to6  cargo 
ATRIB(2)=10. ,  ATRIB(3)=6., 
,  ATRIB(7)=10. ; 

split  for  next  cargo 


enter  10to6  cargo 
create  one  12tol  cargo 
ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=12. ,  ATRIB(3)=1., 
ATRIB(4)=15. ,  ATRIB(7)=12. ; 

ACT,USERF(5) ,  , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,CWtl; 

ACT/48,,,0012;  enter  12tol  cargo 

CWt2  CREATE,,,,,;  create  one  12to2  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=12 . ,  ATRIB(3)=2., 
ATRIB(4)=15. ,  ATRIB(7)=12.; 

ACT,USERF(5) , , ;  split  for  next  cargo 

GOON/2; 

ACT, , ,CWt2; 

ACT/49,,,0012;  enter  12to2  cargo 

CWt5  CREATE,,,,,;  create  one  12to5  cargo 

ASSIGN,  ATRIB(1)=0.,  ATRIB(2)=12 . ,  ATRIB(3)=5., 
ATRIB(4)=15. ,  ATRIB(7)=12. ; 

ACT,USERF(5) , ,  ;  split  for  next  cargo 

GOON/2; 

ACT, , ,CWt5; 

ACT/50,,,0012;  enter  12to5  cargo 

JETS  CREATE,,,,,;  create  one  plane/flight 

INFO  ACT ,USERF( 1) , , ;  split  for  next  flight 

GOON/2; 

ACT, 0. ,ATRIB(l) .GT.O. , JETS;  create  next  plane 
DPRT  ACT/1 ,0 . ,ATRIB(1) .GT.O ., ;  plane  departs 

FILL  EVENT, 1,1;  looks  at  onboard  cargo 


I)-7 


PNEW  EVENT, 2,1;  gets  new  cargo 

FLY  ACT/2, USERF (2) , ;  fly  to  next  stop 

ASSIGN,  ATRIB(7)=ATRIB(7)+1 . ;  increase  leg  counter 
ACT, 0. ,1. , DROP; 

DROP  EVENT,3,1;  update  place  (hold) 

FDIR  EVENT,4,1;  plane  direction  change  ? 

CDIR  EVENT, 5,1;  cargo  direction  change  ? 

DOFF  EVENT, 6,1;  cargo  getting  off  ? 

FFIN  EVENT, 7,1;  last  stop  of  plzme 

GOON/1; 

SIT  ACT/3, USERF (4) , USERF (3) .NE.ATRIB (6), FILL;  sit  on  ground 
;  userf(4)  returns  groundtime,  userf(3)  returns  current  stop 
LAST  ACT/4, 0, USERF (3) .EQ.ATRIB (6), ;  at  last  stop 

TERM; 

QOOl  QUEUE(1),0.,,; 
q002  qUEUE(2) ,0, , ,  ; 
q003  qUEUE(3) ,0, , ,  ; 
q004  qUEUE(4),0,,,; 
q005  qUEUE(5) ,0, ,  ,  ; 
q006  qUEUE(6) ,0, , ,  ; 
q007  qUEUE(7) ,0, . ,  ; 
q008  qUEUE(8) ,0, , ,  ; 
q009  qUEUE(9),0,,,; 
qOlO  qUEUE(l0).0,, ,  ; 
qoil  qUEUE(ll) ,0, ,  ,  ; 
q012  qUEUE(12) ,0, ,  ,  ; 

TEMP  qUEUE(19) ,0, , ,  : 

HOLD  qUEUE(20) ,0, , , ; 

DONE  qUEUE(2l) ,0, , ,  ; 

ACT(l) ,0. ,1.  ,  ; 

CARG  EVENT,8,1; 

TERM; 

ENDNETWORK ; 


Appendix  E.  The  CARGO. FOR  File  for  SLAM  Inserts 


PROGRAM  MAIN 
DIMENSION  NSETOOOOOOO) 

INCLUDE  'SLAM$DIR:PARAM.INC' 

C0MM0N/SC0M1/ATRIB(MATRB) ,  DD(MEQT),  DDLCMEQT),  DTNOW,  II,  MFA, 
IMSTOP,  NCLNR,  NCRDR,  NPRNT,  NNRUN,  NNSET,  NTAPE,  SS(MEQT), 
2SSL(MEqT),  TNEXT,  TNOW,  XX(MMXXV) 

PARAMETER  (MAXQUE=15.  MAXFLT=1000,  MAXMSN=100) 
COMMON/UCOMl/NUMQUE,  NUMFLT,  NATCAR,  NATFLT,  ILEGS,  lEVERY 
C0MM0N/UC0M2/ENDAT,  BSTATS,  ESTATS,  IMSSNS,  NFLOWN 
C0MM0N/UC0M3/MAXSTP(MAXMSN) .  FLTMSN(MAXFLT)  ,  CARGON(MAXFLT) 
COMMON/UCOM4/CDIRCT(MAXQUE,MAXQUE) ,  FDIRCT(MAXMSN , 13) 
C0MM0N/UC0M5/CMSI0N(MAXqUE**2,5) ,  DEMAND (MAXqUE.MAXqUE) 

COMMON  qSET(3000000) 

EqUIVALENCE  (NSET(l) ,qSET(l)) 

NNSET=3000000 

NCRDR=5 

NPRNT=6 

NTAPE=7 

NPLQT=2 

C**  Next  lines  to  pass  common  information  to  subroutines.  These  need 
C**  to  be  adjusted  for  changes  to  network  (e.g.,  number  of  airports, 
C**  number  of  cargo  or  aircraft  attributes).  Also,  for  all  routines 
C**  the  COMMON  block  matrix  dimensions  must  be  adjusted  when  needed. 
C**  Current  limitations:  12  legs/flight,  18  stops/ton  of  cargo. 

NUMqUE  =  12 
NATCAR  =  98 
NATFLT  =  47 
ENDAT  =  720. 

BSTATS  =  720. 

ESTATS  =  1419.9999 

CALL  SLAM 

STOP 

END 


C**  This  subroutine  takes  care  of  initial  activities  required,  such 
C**  as  initial  opening  of  files  for  reading  and  writing. 

SUBROUTINE  INTLC 

INCLUDE  'SLAM$DIR:PARAM.INC' 

C0MM0N/SC0M1/ATRIB(MATRB) ,  DD(MEqT) ,  DDL(MEqT) ,  DTNOW,  II,  MFA, 
IMSTOP,  NCLNR,  NCRDR,  NPRNT,  NNRUN,  NNSET,  NTAPE,  SS(MEqT) , 
2SSL(MEqT),  TNEXT,  TNOW,  XX(MMXXV) 

PARAMETER  (MAXqUE=15,  MAXFLT=1000,  MAXMSN=100) 
COMMON/UCOMl/NUMqUE,  NUMFLT,  NATCAR,  NATFLT,  ILEGS,  lEVERY 
C0MM0N/UC0M2/ENDAT,  BSTATS,  ESTATS,  IMSSNS,  NFLOWN 
C0MM0N/UC0M3/MAXSTP(MAXMSN) ,  FLTMSN(MAXFLT)  ,  CARGON (MAXFLT) 
C0MM0N/UCCM4/CDIRCT(MAXqUE,MAXqUE) ,  FDIRCT(MAXMSN , 13) 


C0MM0N/UC0M5/CMSI0H(MAXQUE**2.5)  ,  DEMAND (MAXQUE.MAXQUE') 
DIMENSION  TEMP (14) 

OPEN (UNIT= 1 , FILE= ' SCHED . DAT ' , STATUS= ' OLD  0 
OPEN (UNIT=3 , FILE= ' DEMAND . DAT ' , STATUS= 'OLD  0 
OPEN (UNIT=4 . FILE= ' CDIRCT . DAT ' , STATUS= ' OLD '  ) 

OPEN (UNIT=8 , F ILE= ' LEGS . OUT ' , STATUS= 'UNKNOWN ' ) 

OPEN (UNIT=9 , FILE= ' QUEUES . OUT ' , STATUS= ' UNKNOWN ' ) 

OPEN (UNIT= 10 , FILE= ' CMSSION . DAT ' , STATUS= ' OLD ' ) 

OPEN (UNIT= 1 1 , FILE= ' FDIRCT . DAT ' , STATUS= ' OLD ' ) 

OPEN (UNIT=30 , FILE= ' FLEGS . TMP ' . STATUS= ' UNKNOWN ' ) 

OPEN (UNIT=3 1 , FILE= ' EVERY . TMP ' . STATUS= ' UNKNOWN ' ) 

OPEN (UNIT=99 , FILE= ' OUT . OUT' ,STATUS= ' UNKNOWN ' ) 


c  The  next  lines  read  the  cargo  demand,  direction  changes,  and 
c  mission  number  changes  between  the  origin-destination  pairs  and 
c  converts  it  into  internal  matrix  form  mr>r<^  easily  used  later 
c  (in  USERF(5)  for  cargo  demand  generation  and  in  CDIR  for 
c  DIRECTion  and  MiSSION  changes) . 

100  READ(UNIT=3,FMT=' (2(14) ,F10.2) ' ,END=110)  IREADl,  IREAD2,  READ3 
IF(  READ3  .EQ.  0.)  READ3  =  .000000001 
BTWEEN  =  ENDAT  /  READ3 
DEMAND ( IREADl, IREAD2)  =  BTWEEN 
GOTO  100 

110  CLOSE (UNIT=3,STATUS=' KEEP') 

120  READ(UNIT=4,FMT=' (2(14) ,F6.0) ' ,END=130)  IREADl,  IREAD2,  READS 
CDIRCT(IREAD1,IREAD2)  =  READS 
GOTO  120 

130  CL0SE(UNIT=4,STATUS='KEEP') 

140  READ(UNIT=10,FMT=' (5(F4.0)) ' ,END=160)  (TEMP(KK) ,KK=1 ,5) 

1  =  1  +  1 
DO  150,  J=l,  5 

CMSI0N(1,J)  =  TEMP(J) 

150  CONTINUE 
GOTO  140 

160  CLOSE (UNIT= 10, STATUS=' KEEP') 


c  Now  we  read  in  the  stops  where  aircraft  are  changing  directions 
c  into  the  FDIRCT  matrix  for  later  use  in  DDIR. 

170  READ(UNIT=11,FMT='(13(F3.0))' ,END=190)  (TEMP(KK) ,KK=1 , 13) 

IT  =  IT  +  1 
DO  180,  J=l,13 

FDIRCT(IT,J)  =  TEMP(J) 

180  CONTINUE 
GOTO  170 

190  CLOSE (UNIT=11,STATUS=' KEEP') 


RETURN 


END 


C**  Here  is  the  beginning  of  all  the  events.  Note  that  the  events 
C**  really  only  directly  affect  aircraft  in  the  SLAM  code.  The  cargo 
C**  is  adjusted  by  the  swapping  of  attribute  values  indirectly 
C**  through  the  sequence  of  events. 

SUBROUTINE  EVENT (I) 

INCLUDE  'SLAM$DIR:PARAM.INC' 

C0MM0N/SC0M1/ATRIB(MATRB)  ,  DD(MEC)T),  DDL(MEQT),  DTNOW,  II,  MFA, 
IMSTOP,  NCLNR,  NCRDR,  NPRNT,  NNRUN,  NNSET,  NTAPE,  SS(MEQT), 
2SSL(MEQT),  TNEXT,  TNQW,  XX(MMXXV) 

PARAMETER  (MAXqUE=15,  MAXFLT=1000,  MAXMSN=100) 
COMMON/UCOMl/NUMQUE,  NUMFLT,  NATCAR,  NATFLT,  ILEGS,  lEVERY 
C0MM0N/UC0M2/ENDAT,  BSTATS,  ESTATS,  IMSSNS,  NFLOWN 
C0MM0N/UCQM3/MAXSTP(MAXMSN; ,  FLTMSN(MAXFLT) ,  CARGON(MAXFLT) 
COMMON/UCOM4/CDIRCT(MAXqUE,MAXQUE) ,  FDIRCT(MAXMSN , 13) 
C0MM0N/UC0M5/CMSI0N(MAXqUE**2,5) .  DEMAND (MAXqUE.MAXqUE) 
DIMENSION  A(IOO),  EVERY (8 ) ,  FLEGS(9) 

GOTO ( 1000 , 2000,3000 ,4000 , 5000 , 6000 , 7000 , 8000)  I 

C**  This  is  FILL.  Fill  in  cargo  departure  time,  next  stop, 
c**  arrival  time  at  next  stop  for  cargo  already  onboard. 

1000  CONTINUE 

JJ  =  INT(  3  *  ATRIB(7)  ) 

1010  NEXT  =  MMFE(20) 

IF  (NEXT  .Eq.  0)  GOTO  1030 
CALL  RM0VE(-NEXT,20,A) 


c  find  cargo  on  plane,  adjust  cargo  attributes  to  reflect  cargo  now 
c  at  new  location,  put  back  in  HOLD.  Note  that  cargo  dropping 
c  occurs  later. 

IF(  A(5)  .Eq.  ATRIB(2)  )  THEN 
DO  1020,  K=9,  NATCAR-4,  5 
IF  (  A(K)  .Eq.  0.)  THEN 
A(K-l)  =  TNOW 
A(K)  =  A'T'RIB(2) 

A(K+1)  -  ATRIB(3) 

A(K+2)  =  ATRIB(JJ  +  11) 

A(K+3)  =  TNOW  +  ATRIB(JJ  +  10) 

CALL  FFILE(19,A) 

GOTO  1010 
ENDIF 

1020  CONTINUE 
ELSE 

CALL  FFILE(19,A) 

GOTO  1010 
ENDIF 


1030  NEXT  =  MMFE(19) 


IF(  NEXT  .EQ.  0  )  GOTO  1040 
CALL  RM0VE(-NEXT,19,A) 

CALL  FFILE(20,A) 

GOTO  1030 

1040  CONTINUE 
RETURN 

C**  This  is  PNEW,  which  looks  for  cargo  at  the  current  location  of 
C**  the  aircraft  to  be  picked  up,  picks  it  up  when  appropriate, 

C**  adjusts  attributes  of  cargo  to  reflect  getting  on  plane,  and 
C**  puts  such  cargo  in  HOLD  status. 

2000  CONTINUE 

JJ  =  INT(  3  *  ATRIB(7)  ) 

NOWAT  =  INT(  ATRIB(JJ  +  8)  ) 

IF(  ATRIB(4)  -  CARG0N(INT(ATRIB(2)))  .EQ.  0.  )  GOTO  2070 

c  look  at  current  location  for  cargo  to  pick  up. 

2010  NEXT  =  MMFE(NOWAT) 

IF(NEXT  .EQ.  0)  GOTO  2060 
CALL  RMOVE (-NEXT, NOWAT, A) 

c  Note:  liext  IF  compares  directions  and  allows  a  range  for  allowable 
c  assignment.  Modification  might  expand  on  this  decision  logic. 

IF(  (A(4)  .GE.  ATRIB(5)-5.)  .AND. 

1  (A(4)  .LE.  ATRIB(5)+5.)  )  THEN 

IF(  A(l)  .EQ.  0.)  THEN 

DO  2020,  K=9,  NATCAR-4,  5 
IF  (  A(K)  .EQ.  0.)  THEN 
A(5)  =  A1RIB(2) 

A(6)  =  ATRIB(3) 

A(K-l)  =  TNOW 
A(K)  =  ATRIB(2) 

A(K+1)  =  ATRIB(3) 

A(K+2)  =  ATRIBdJ  +  11) 

A(K+3)  =  TNOW  +  ATRIBdJ  +  10) 

CALL  FFILE(20,A) 

CARG0N(INT(ATRIB(2)))  =  CARG0N(INT(ATRIB(2) ) )  +  1. 

IF(  ATRIB(4)-CARG0N(INT(ATRIB(2)))  .EQ.  0.)  GOTO  2060 
GOTO  2010 
END  IF 

2020  CONTINUE 

ELSE 

I ROW  =  0 

DO  2030,  1=1,  NUMQUE**2 
IROW  =  I  ROW  +  1 

IF(  (A(7)  .EQ.  CMSIONd,!))  .AND. 

1  (A(3)  .EQ.  CMSIONd, 2))  )  GOTO  2040 

2030  CONTINUE 

2040  IF(  (ATRIBd)  .  EQ  .  CMSIONCIROW  ,3) )  .OR. 

1  (ATRIR(l)  .EQ.  CMSIONCIROW, 4))  .OR. 

2  (ATRIBd)  .EQ.  CMSIONCIROW  ,5) )  )  THEN 


I 


DO  2050,  K=9,  NATf;AR-4,  5 
IF  (  A(K)  .EQ.  0.)  THEN 
A(5)  =  ATRIB(2) 

A(6)  =  ATRIB(3) 

A(K-l)  =  TNOW 
A(K)  =  ATRIB(2) 

A(K+1)  =  ATRIB(3) 

A(K+2)  =  ATRIB(JJ  +  11) 

A(K43)  =  TNOW  +  ATRIB(JJ  +  10) 

CALL  FFILE(20,A) 

CARG0N(INT(ATRIB(2)))  =  CARG0N(INT(ATRIB(2) ) )  +  1. 
IF(ATRIB(4)-CARG0N(INT(ATRIB(2))) .EQ.O.)  GOTO  2060 
GOTO  2010 
END  IF 

2050  CONTINUE 

ELSE 

CALL  FFILE(19,A) 

END  IF 
END  IF 
ELSE 

CALL  FFILE(19,A) 

ENDIF 
GOTO  2010 

2050  NEXT  =  MMFE(19) 

IF(  NEXT  .EQ.  0  )  GOTO  2070 
CALL  RM0VE(-NEXT,19,A) 

CALL  FFILE(NOWAT,A) 

GOTO  2060 

2070  CONTINUE 
RETURN 

C**  Dropping  off  cargo.  This  subroutine  will  have  to  find  out  whether 
C**  cargo  is  destined  for  the  next  plane  stop,  whether  it  will  stay  on 
C**  the  plane,  or  whether  it  is  getting  off  (into  the  queue)  h'  -^e. 

C**  Cargo  at  destination  might  be  problem  -  will  it  get  to  top  of  FIFO 
C**  list  to  process  to  reporting  block  Can  entity  be  inserted  at 
C**  top  of  queue 

C+*****  this  is  DROP 
3000  CONTINUE 

IF(  INT(ATRIB(7))  .GT.  MAXSTP(INT(ATRIB( 1) ) )  )  THEN 
MAXSTP(INT(ATRIB(1)))  =  INT(ATRIB(7) ) 

ENDIF 

JJ  =  INT  (  3  ♦  ATRIB(7)  ) 

PLACE  =  ATRIBCJJ  +  8) 

NOWAT  =  INT(  ATRIBCJJ  +  8)  ) 


c  updating  cargo  location 
3010  NEXT  =  MMFE(20) 


IF  (i\lEXT  .EQ.  0)  GOTO  3060 
CALL  RM0VE(-NEXT,20,A) 

IF  (  A (5)  .EQ.  ATRIB(2)  )  THEN 

IF(  (TNOW  .GE.  BSTATS)  .AND.  (TNOW  .LT.  ESTATS)  )  THEN 
ILEGS  =  ILEGS  +  1 
FLEGS(l)  =  ATRIB(l) 

FLEGS(2)  =  ATRIB(2) 

FLEGS(3)  =  ATRIB(3) 

FLEGS(4)  =  ATRIB(4) 

FLEGS(5)  =  ATRIB(7) 

FLEGS(6)  =  A(2) 

FLEGS(7)  =  A(3) 

c  This  next  loop  finds  the  time  the  cargo  got  on. 

DO  3020,  1=9,  NATCAH-4,  5 

IF(  A(I)  .EQ.  ATRIB(2)  )  T.HEN 
IGQTON  =  I 
GOTO  3030 
END  IF 

3020  CONTINUE 

3030  FLEGS(8)  =  A(IGOTON-l) 

FLEGS(9)  =  TNOW 

WRITE(UNIT=30,FMT=*)  (FLEGS(KK) ,KK=1,9) 

END  IF 

C**  update  place,  put  at  destination  or  back  onboard. 

A(7)  =  PLACE 

IF  (  A(7)  .EQ.  A(3)  )  THEN 
DO  3040,  1=8,  NATCAR-5,  5 
IF(  A(I)  .EQ.  0.)  THEN 
A(I)  =  TNOW 
GOTO  3050 
ENDIF 

3040  CONTINUE 

c  cargo  at  destination,  put  in  DONE. 

3050  CALL  FILEM(21,A) 

CARG0N(INT(ATRIB(2)))  =  CARGON(INT(ATRIB (2) ) )  -  1. 
ELSE 

c  cargo  not  at  destination,  put  back  in  HOLD. 

CALL  FFILE(19,A) 

ENDIF 

ELSE 

CALL  FFILE(19,A) 

ENDIF 
GOTO  3010 

3060  NEXT  =  MMFE(19) 

IF(  NEXT  .EQ.  0  )  GOTO  3070 
CALL  RM0VE(-NEXT,19,A) 

CALL  FFILE(20,A) 

GOTO  3060 


3070  CONTINUE 


RETURN 


C**  This  is  FDIR.  Check  to  see  if  plane  direction  needs  to  change. 
4000  CONTINUE 

ATRIB(5)  =  FDIRCT(INT(ATRIB(1)) ,INT(ATRIB(7))+1) 

RETURN  , 


C**  This  is  CDIR  which  checks  to  see  if  cargo  direction  and/or  mssion 
C**  needs  to  change.  Note  that  all  cargo,  even  if  changing,  is  put 
C**  back  in  HOLD.  It  is  taken  out,  if  necessary,  in  the  next  event. 


5000  CONTINUE 
5010  NEXT  =  MMFE(20) 

IF  (  NEXT  .EQ.  0)  GOTO  5040 
CALL  RM0VE(-NEXT,20,A) 

IF  (  A(5)  .EQ.  ATRIB(2)  )  THEN 


c  The  next  lines  check  and  change  direction  and  mission, 
c  respectively,  as  input  in  the  CDIRCT.DAT  and  MSSI0N.DAT  files, 
c  This  is  based  on  current  location  and  final  destination. 

A(4)  =  CDIRCTC  INT(A(7)),  INT(A(3))  ) 

IROW  =  0 

DO  5020,  1=1,  NUMQUE**2 
IROW  =  IROW  +  1 

IF(  (A(7)  .EQ.  CMSIONdROW,!))  .AND. 

1  (A(3)  .EQ.  CMSIONdROW, 2))  )  GOTO  5030 

5020  CONTINUE 

5030  IF(  (CMSIONdROW, 3)  .EQ.  0.)  .AND. 

1  (CMSIONdROW, 4)  .EQ.  0.)  .AND. 

2  (CMSIONdROW, 5)  .EQ.  0.)  )  THEN 

Ad)  =  0. 

ELSE 

Ad)  =  -1. 

END  IF 

CALL  FFILE(19,A) 

ELSE 

CALL  FFILE(19,A) 

ENDIF 
GOTO  5010 


5040  NEXT  =  MMFE(19) 

IF(  NEXT  .EQ.  0  )  GOTO  5050 
CALL  RM0VE(-NEXT,19,A) 

CALL  FFILE(20,A) 

GOTO  5040 


5050  CONTINUE 
RETURN 


C**  This  IS  DOFF,  which  searches  for  other  cargo  getting  off  for  some 
C*+  reason.  Note  that  both  plane  and  cargo  directions  could  have  been 
C**  changed  in  previous  events. 


6000  CONTINUE 

JJ  =  INT(  3  *  ATRIB(7)  ) 

PLACE  =  ATRIB(JJ  +  8) 

NOWAT  =  INT(  ATRIB(JJ  +  8)  ) 

IF  (  PLACE  .EQ.  ATRIB(6)  )  RETURN 


c  checking  hold  for  other  cargo  getting  off 
6010  NEXT  =  MMFE(20) 

IF  (  NEXT  .EQ.  0  )  GOTO  6040 
CALL  RM0VE(-NEXT,20,A) 

IF  (  A(5)  .EQ.  ATRIB(2)  )  THEN 

c***  if  going  right  direction,  AND,  mission  same  as  plane  or  not  0, 
c***  will  stay  on  the  plane. 

c  Note:  Next  IF  compares  directions  and  allows  a  range  for  allowable 
c  assignment.  Modification  might  expand  on  this  decision  logic. 

IF(  (A(4)  .GE.  ATRIB(5)-5.)  .AND. 

1  (A (4)  .LE.  ATRIB(5)+5.)  )  THEN 

IF(  A(l)  .NE.  0.)  THEN 

IROW  =  0 

DO  6020,  I-l,  NUMQUE*NUMQUE 
IROW  =  IROW  +  1 

IF(  (A(7)  .EQ.  CMSI0N(IR0W,1))  .AND. 

2  (A(3)  .EQ.  CMSI0N(IR0W,2))  )  GOTO  6030 

6020  CONTINUE 

6030  IF(  (ATRIB(l)  .EQ.  CMSI0N(IR0W,3))  .OR. 

1  (ATRIB(l)  .EQ.  CMSI0N(IR0W,4))  .DR. 

2  (ATRIB(l)  .EQ.  CMSI0N(IR0W,5))  )  THEN 
CALL  FFILE(19,A) 

ELSE 

CALL  FFILE(NOWAT,A) 

CARG0N(INT(ATRIB(2)))  =  CARGON(INT (ATRIB(2) ) )  -  1. 
END  IF 
ELSE 

CALL  FFILE(19,A) 

END  IF 


c  otherwise  will  get  off  plane  at  current  stop. 

ELSE 

CALL  FFILE(NOWAT,A) 

CARG0N(INT(ATRIB(2)))  =  CARG0N(INT(ATRIB(2) ))  -  1. 

ENDIF 

ELSE 

CALL  FFILE(19,A) 

ENDIF 
GOTO  6010 

6040  NEXT  =  MMFE(19) 

IF(  NEXT  .EQ.  0  )  GOTO  6050 
CALL  RM0VE(-NEXT,19,A) 

CALL  FFILE(20,A) 


GOTO  6040 


6050  CONTINUE 
RETURN 


C**  This  is  FFIN,  which  takes  care  of  the  situation  when  a  flight  is  at 
C**  the  last  stop  (the  plane  arrives  at  home  base) .  All  cargo  in  HOLD 
C**  on  the  plane  is  offloaded  at  current  location. 

7000  CONTINUE 

JJ  =  INT(  3  *  ATRIB(7)  ) 

PLACE  =  ATRIBCJJ  +  8) 

NOWAT  =  INT(  ATRIBCJJ  +  8)  ) 

IF  (PLACE  .NE.  ATRIB(6)  )  RETURN 

7010  NEXT  =  MMFE(20) 

IF  (NEXT  .EQ.  0)  GOTO  7020 
CALL  RM0VE(-NEXT,20.A) 

IF  (  A(5)  .EQ.  ATRIB(2)  )  THEN 

CALL  FFILE(NOWAT,A) 

CARG0N(INT(ATRIB(2)))  =  CARG0N(INT(ATRIB(2) ) )  -  1. 

ELSE 

CALL  FFILE(19,A) 

END  IF 
GOTO  7010 

7020  NEXT  =  MMFE(19) 

IF(  NEXT  .EQ.  0  )  GOTO  7030 
CALL  RM0VE(-NEXT,19,A) 

CALL  FFILE(20,A) 

GOTO  7020 

7030  CONTINUE 
RETURN 


c  This  is  CARG,  for  writing  cargo  atributes  to  common  matrix  EVERY, 
c  Note:  unlike  other  above  routines,  this  one  is  using  attributes 
c  of  the  cargo  entities. 

8000  CONTINUE 

IF(  (TNOW  .GE.  BSTATS)  .AND.  (TNOW  .LT.  ESTATS)  )  THEN 
I EVERY  =  I EVERY  +  1 
DO  8010,  1=9,  NATCAR-4,  5 
EVERY (1)  =  ATRIB(2) 

EVERY(2)  =  ATRIB(3) 

IF(  I  .EQ.  9)  THEN 
EVERY(3)  =  ATRIB(2) 

ELSE 

EVERY(3)  =  ATRIB(I-3) 

ENDIF 

EVERY (4)  =  ATRIB(I) 

EVERY(5)  =  ATRIB(I+1) 

EVERY(6)  =  ATRIB(I+4) 


EVERY(7)  =  ATRIB(I-l) 

EVERY(8)  =  ATRIB(I+4)  -  ATRIB(I-l) 

WRITE (UNIT=31,FMT=*)  (EVERY(KK) ,KK=1,8) 

8010  CONTINUE 
END  IF 
RETURN 

END 

C***  Begin  user  functions 
FUNCTION  USERF(I) 

INCLUDE  'SLAM$DIR:PARAM.INC' 

C0MM0N/SC0M1/ATRIB(MATRB),  DD(MEQT),  DDL(MEQT),  DTNOW,  II,  MFA, 
IMSTOP,  NCLNR,  NCRDR,  NPRNT,  NNRUN,  NNSET,  NT APE.  SS(MEQT) , 
2SSL(MEqT).  TNEXT,  TNOW,  XX(MMXXV) 

PARAMETER  (MAXQUE=15,  MAXFLT=1000,  MAXMSN=100) 
COMMON/UCOMl/NUMQUE,  NUMFLT,  NATCAR,  NATFLT,  ILEGS ,  lEVERY 
C0MM0N/UC0M2/ENDAT,  BSTATS ,  ESTATS,  IMSSNS,  NFLOWN 
C0MM0N/UC0M3/MAXSTP(MAXMSN) ,  FLTMSN(MAXFLT) ,  CARGON(MAXFLT) 
C0MM0N/UC0M4/CDIRCT(MAXQUE.MAXQUE) ,  FDIRCT(MAXMSN , 13) 
C0MM0N/UC0M5/CMSI0N(MAXQUE**2,5) ,  DEMAND (MAXQUE.MAXQUE) 

G0T0(1,2,3,4,5)  I 

C**  Read  attribute  values,  adjust  depart  time  to  time  from  TNOW. 

1  CONTINUE 

READ (UNIT= 1 , FMT=8 , END= 10 )  ( ATRIB ( J ) , J= 1 , 1 1 ) 

8  F0RMAT(lx,F3.0,F4.0.6(F3.0) ,F7 .2 ,F5 . 2 ,F3 . 0) 

READ (UNIT= 1 , FMT=9 , END= 10 )  (ATRIB ( J ) , J= 12 , 29 ) 
READ(UNIT=1,FMT=9,END=10)  (ATRIB(J) , J=30 .NATFLT) 

9  F0RMAT(lx,6(F5.2,F5.2.F3.0)) 

IF(  (TNOW  .GE.  BSTATS)  .AND.  (TNOW  .LT.  ESTATS)  )  THEN 
NUMFLT  =  NUMFLT  +  1 
END  IF 

NFLOWN  =  NFLOWN  +  1 
FLTMSN (NFLOWN)  =  ATRIB (1) 

IF(  INT(ATRIB(1))  .GT.  IMSSNS)  IMSSNS  =  INT(ATRIB (1) ) 

USERF  =  ATRIB(9)  -  TNOW 
RETURN 


C**  End-of-file.  Kill  aircraft  creation  sequence. 

10  ATRIB(l)  =  0 
USERF  =  0 

CLOSE(UNIT= 1 , STATUS= ' KEEP ’ ) 

RETURN 

C**  Figuring  flying  time  to  next  stop. 

2  CONTINUE 

J  =  INT(  3.  *  ATRIB(7)  +  10.) 

USERF  =  ATRIB(J) 


I-:  id 


RETURN 


C**  Figuring  what  the  current  stop  location  is. 

3  CONTINUE 

J  =  INT(  3.  *  ATRIB(7)  +8.) 

USERF  =  ATRIB(J) 

RETURN 

C**  Figuring  ground  time  till  next  departure. 

4  CONTINUE 

J  =  INT(  3.  ♦  ATRIB(7)  +9.) 

USERF  =  ATRIB(J) 

RETURN 

C**  Get  values  for  time  between  creation  for  cargo. 

5  CONTINUE 

IROW  =  INT(  ATRIB(2)  ) 

ICOL  =  INT(  ATRIB(3)  ) 

USERF  =  DEMAND (IROW, ICOL) 

RETURN 

END 

C**  Final  subroutine  called  by  SLAM  at  end  of  simulation.  Includes 
C**  calculation  and  reporting  of  delay  figures  (through  called 
C**  subroutines  using  data  passed  through  common  EVERY  information. 
C**  Also  closes  all  opened  files. 

SUBROUTINE  OTPUT 

INCLUDE  ’SLAM$DIR:PARAM.INC' 

C0MM0N/SC0M1/ATRIB(MATRB) ,  DD(MEQT),  DDL(MEQT),  DTNOW,  II,  MFA, 
IMSTOP,  NCLNR,  NCRDR,  NPRNT,  NNRUN,  NNSET,  NTAPE,  SS(MEqT), 
2SSL(MEQT),  TNEXT,  TNOW,  XX(MMXXV) 

PARAMETER  (MAXQUE=15,  MAXFLT=1000,  MAXMSN=100) 
COMMON/UCOMl/NUMQUE,  NUMFLT,  NATCAR,  NATFLT,  ILEGS,  lEVERY 
C0MM0N/UC0M2/ENDAT,  BSTATS,  ESTATS,  IMSSNS,  NFLOWN 
C0MM0N/UC0M3/MAXSTP(MAXMSN) ,FLTMSN(MAXFLT) ,  CARGON(MAXFLT) 
C0MM0N/UCQM4/CDIRCT(MAXQUE,MAXQUE) ,  FDIRCT(MAXMSN , 13) 
C0MM0N/UC0M5/CMSI0N(MAXqUE**2,5) ,  DEMAND (MAXqUE,MAXqUE) 

200  CONTINUE 

301  CALL  LEGS 

CLOSE (UNIT=8 , STATUS= ' KEEP ' ) 

CL0SE(UNIT=30 ,STATUS= 'DELETE' ) 

401  CALL  ODELAY 

CLOSE (UNIT=9 , STATUS= ’ KEEP ' ) 

CLOSE (UNIT=31, ST ATUS=' DELETE') 


c  The  next  write  is  for  debugging,  in  case  row  dimension  in  COMMON 
c  blocks  for  matrix  EVERY  is  exceeded. 


WRITE (UNIT=99,FMT=*)  '  NUMBER  OF  ROWS  IN  EVERY  =  MEVERY 
WRITE (UNIT=99,FMT=*)  '  NUMBER  OF  ROWS  IN  FLEGS  =  MLEGS 
WRITE (UNIT=99,FMT=*)  '  FLIGHTS  TAKEOFFS  IN  TIME  SPAN=  ' .NUMFLT 
DO  210,  1=1,  IMSSNS 

WRITE(UNIT=99,FMT=209)  I,  MAXSTP(I) 

209  FORMATC'  MAXIMUM  LEGS  ON  MISSION',  13 ,'=  M4) 

210  CONTINUE 

CLOSE (UNIT=99 , STATUS= ' KEEP ’ ) 

RETURN 

END 

C**  This  next  subroutine,  called  by  OTPUT,  provides  the  breakdown  of 
C**  what  cargo  is  on  each  flight  by  origin-destination  pairs,  using 
C**  the  FLEGS  data.  Output  file  created  is  LEGS. OUT. 

SUBROUTINE  LEGS 

INCLUDE  'SLAM$DIR:PARAM.INC' 

C0MM0N/SC0M1/ATRIB(MATRB) ,  DD(MEQT) ,  DDL(MEQT),  DTNDW,  II,  MFA, 
IMSTOP,  NCLNR,  NCRDR,  NPRNT,  NNRUN,  NNSET,  NTAPE,  SS(MEQT) , 
2SSL(MEQT),  TNEXT,  TNOW,  XX(MMXXV) 

PARAMETER  (MAXqUE=15,  MAXFLT=1000,  MAXMSN=100) 
COMMON/UCOMl/NUMQUE,  NUMFLT,  NATCAR,  NATFLT,  ILEGS,  lEVERY 
C0MM0N/UC0M2/ENDAT,  BSTATS,  ESTATS,  IMSSNS,  NFLOWN 
C0MM0N/UC0M3/MAXSTP(MAXMSN) ,  FLTMSN(MAXFLT) ,  CARGON(MAXFLT) 
C0MM0N/UC0M4/CDIRCT(MAXQUE,MAXQUE) ,  FDIRCT(MAXMSN, 13) 
C0MM0N/UC0M5/CMSI0N(MAXQUE**2,5) ,  DEMAND (MAXQUE,MAXQUE) 
DIMENSION  DELAY(10000,11)  ,  FLEGS(9) 

CLOSE (UNIT=30 , STATUS= ' KEEP ' ) 

OPEN (UNIT=30 , FILE= ’ FLEGS . TMP ' , STATUS= ’ OLD ' ) 

LOWFLT  =  10000 

300  READ(UNIT=30,FMT=*,END=330)  (FLEGS (KK)  ,KK=1 , 9) 

IF(  INT(FLEGS(2))  .LT.  LOWFLT)  LOWFLT  =  INT(FLEGS (2) ) 

DO  320,  IR0W=1,  ILEGS 
DO  310,  N=l,  ILEGS 

IF(  DELAY(N,1)  .EQ.  0.)  THEN 
DELAY (N,l)  =  FLEGS (1) 

DELAY (N, 2)  =  FLEGS (2) 

DELAY(N,3)  =  FLEGS(3) 

DELAY(N,4)  =  FLEGS(4) 

DELAY(N,5)  =  FLEGS(5) 

DELAY(N,6)  =  FLEGS(6) 

DELAY(N,7)  =  FLEGS(7) 

DELAY (N, 8)  =  FLEGS (8) 

DELAY(N,9)  =  FLEGS(9) 

PELAY(N,10)  =  1. 

DELAY(N,11)  =  FLEGS(9)  -  FLEGS(8) 

NN  =  NN  +  1 
GOTO  300 

ELSEIFC  (  DELAY(N,2)  .EQ.  FLEGS(2)  )  .AND. 

(  DELAY(N,5)  . EQ .  FLEGS(5)  )  .AND. 


1 


.AND. 

.AND. 


)  THEN 


CARGO  CARGO 


NUMBER  ORIG  DEST 


2  (  DELAY(N,6)  .EQ.  FLEGS(6)  ) 

3  (  DELAY (N, 7)  .EQ.  FLEGS(7)  ) 

4  (  DELAY (N, 8)  .EQ.  FLEGS(8)  ) 

DELAY(N,10)  =  DELAY(N,10)  +  1. 

GOTO  300 

END  IF 

310  CONTINUE 

320  CONTINUE 
330  CONTINUE 

DO  360,  IFLT=LOWFLT,  LOWFLT+NUMFLT-1 
WRITE (UNIT=8 , FMT=337) 

337  FORMATC/'  FLIGHT  TAIL  MISSON  LEG 

1  'NUMBER  TIME’) 

WRITE (UNIT=8 , FMT=338) 

338  FORMAT (  ’  NUMBER  NUMBER  NUMBER 

1  ’  OF  GOT  ON'/) 

DO  350,  JST0P=1,  MAXSTP(INT(FLTMSN(IFLT))) 

BOARD  =  0. 

DO  340,  N=l,  NN 

IF(  DELAY(N,2)  .EQ.  REAL(IFLT))  THEN 
CAP  =  DELAY(N,4) 

IF(  DELAY(N,5)  .EQ.  REAL(JSTOP))  THEN 
WRITE (UNIT=8,FMT=339)  INT(DELAY(N,2) ) , 

1  INT(DELAY(N,3)) ,  INT(DELAY (N , 1) ) , 

2  INT(DELAY(N,5)) ,  INT(DELAY(N ,6) ) , 

3  INT(DELAY(N,7)) ,  INT(DELAY(N , 10) ) , 

4  DELAY (N, 8) 

339  F0RMAT(I5,I8,I8,I8,I7,I7,I8,F10.2) 

BOARD  =  BOARD  +  DELAY(N,10) 

END  IF 
END  IF 

340  CONTINUE 

WRITE (UNIT=8,FMT=349)  IFLT, INT(CAP) , JSTOP , INT(CAP-BOARD) 

349  F0RMAT(I5, 5X,’CAPACITY[’, 12, ’] ’,4X, 13, 12X, 'UNUSED:  ',12/) 

350  CONTINUE 
360  CONTINUE 

RETURN 

END 


C**  This  is  QDELAY,  called  by  OTPUT.  This  subroutine  reports  how 
C**  much  delay  cargo  undergoes,  by  origin-destination  pair.  The 
C**  output  file  is  QUEUES. OUT. 

SUBROUTINE  QDELAY 

INCLUDE  'SLAM$DIR:PARAM.INC’ 

C0MM0N/SC0M1/ATRIB(MATRB) ,  DD(MEQT) ,  DDL(MEQT),  DTNOW,  II,  MFA, 
IMSTOP,  NCLNR,  NCRDR,  NPRNT,  NNRUN,  NNSET,  NTAPE,  SS(MEQT), 
2SSL(MEQT),  TNEXT,  TNOW,  XX(MMXXV) 

PARAMETER  (MAXQUE=15,  MAXFLT=1000,  MAXMSN=100) 
COMMON/UCOMl/NUMQUF,  NUMFLT,  NATCAR,  NATFLT,  ILEGS,  lEVERY 
C0MM0N/UC0M2/ENDAT,  BSTAIS,  ESTATS ,  IMSSNS,  NFLOWN 
C0MM0N/UC0M3/MAXSTP(MAXMSN) ,  FLTMSN(MAXFLT) ,  CARGON (MAXFLT) 


C0MM0N/UC0M4/CDIRCT(MAXQUE,MAXQUE) ,  FDIRCT(MAXMSN, 13) 
C0MM0N/UC0M5/CMSI0N(MAXQUE**2,5) ,  DEMAND (MAXQUE.MAXQUE) 
DIMENSION  DELAY(10000,10) ,  EVERY(8) 


CLOSE (UNIT=31 , STATUS= ' KEEP ' ) 

OPEN (UNIT=31 , FILE= ' EVERY . TMP ’ , STATUS= ’ OLD ') 

400  READ(UNIT=31.FMT=*,END=420)  (EVERY(KK) ,KK=1 ,8) 
IF(  EVERY (4)  -EQ.  0.)  GOTO  400 
DO  410,  N=l,  lEVERY 

IF(  DELAY(N,1)  .EQ.  0.)  THEN 
DELAY(N,1)  =  EVERY (1) 

DELAY (N, 2)  =  EVERY (2) 

DELAY (N, 3)  EVERY (3) 

DELAY(N,4)  =  EVERY(4) 

DELAY(N,5)  =  EVERY(5) 

DELAY (N, 7)  =  EVERY (7) 

DELAY(N,8)  =  EVERY(8) 

DELAY(N,9)  =  1. 

DELAY(N,10)  =  EVERY(8) 

NN  =  NN  +  1 
GOTO  400 

ELSEIFC  (  DELAY(N,1)  . EQ .  EVERY(l)  )  .AND. 

1  (  DELAY (N, 2)  .EQ.  EVERY (2)  )  .AND. 

2  (  DELAY(N,3)  .EQ.  EVERY(3)  )  .AND. 

3  (  DELAY(N,4)  .EQ.  EVERY(4)  )  )  THEN 

DELAY(N,9)  =  DELAY(N,9)  +  1. 

DELAY(N,10)  =  DELAY(N,10)  +  EVERY(8) 

GOTO  400 

ENDIF 
410  CONTINUE 


420  CONTINUE 

WRITE(UNIT=9,FMT=427) 

427  FORMAT (/'  BEGIN  END  STOP  PLANE  ON  DEPART 

1  'NUMBER  MEAN  TOTAL') 

WRITE (UNIT=9 , FMT=428) 

428  FORMAT (  '  PORT  PORT  AT  NUMBER  FLIGHT  TIME 

1  '  OF  DELAY  DELAY'/) 

DO  460,  I0RIG=1,  NUMQUE+1 
DO  450,  JDEST=1,  NUMQUE 
DO  440,  LP0RT=1,  NUMQUE 


DO  430,  N=l,  NN 

IF(  DELAY(N,1)  .EQ.  0.)  GOTO  430 

IF(  (  DELAY(N,1)  .EQ.  REAL(IORIG)  )  .AND. 

1  (  DELAY(N,2)  .EQ.  REAL(JDEST)  )  .AND. 

2  (  DELAY(N,3)  .EQ.  REAL(LPORT)  )  )  THEN 

WRITE(UNIT=9,FMT=429)  INT(  DELAY(N,1)  ), 

1  INT(  DELAY(N,2)  ),  INT(  DELAY(N,3)  ), 

2  INT(  DELAY(N,5)  ),  INT(  DELAY(N,4)  ), 

3  DELAY(N,7),  INT(  DELAY(N,9)  ), 

4  DELAY(N,10)  /  DELAY(N,9),  DELAY(N,10) 

429  F0RMAT(I4,I7,I6,I7,I8,F11 .2,I6,F9.2,F9.2) 


I-;  I  I 


TEMPI  =  TEMPI  +  DELAY(N,10) 

END  IF 

IF(  TEMPI  .GT.  0.)  THEN 
TEMP2  =  TEMP2  +  TEMPI 
TEMPI  =  0. 

END  IF 

430  CONTINUE 

IF(  TEMP2  -GT.  0.)  THEN 
TEMP3  =  TEMP3  +  TEMP2 

WRITE (UNIT=9,FMT=439)  lORIG,  JDEST,  LPORT,  TEMP2 

439  FORMATC/'  SUBTOTAL  DELAY  FOR  CARGO  GOING  FROM  \ 

1  13,'  TO', 13,'  AT  PORT', 14,'  IS  ',F9.2/) 

TEMP2  =  0. 

ENDIF 

440  CONTINUE 

IF(  TEMP3  .GT.  0.)  THEN 
TEMP4  =  TEMP4  +  TEMP3 

WRITE(UNIT=9,FMT=447)  lORIG,  JDEST,  TEMP3 

447  FORMAT ('  TOTAL  DELAY  FOR  CARGO  GOING  FROM ',13, 

1  'TO' ,13,  '  IS  ' ,F9.2/) 

ITEMP  =  ITEMP  +  1 
IF(  ITEMP  .LT.  NUMQUE  )  THEN 
WRITE (UNIT=9,FMT=448) 

448  FORMAT(/'  BEGIN  END  STOP  PLANE  ON  ', 

1  'DEPART  NUMBER  MEAN  TOTAL') 

WRITE(UNIT=9 ,FMT=449) 

449  FORMAT (  '  PORT  PORT  AT  NUMBER  FLIGHT 

1  ’  TIME  OF  DELAY  DELAY'/) 

ENDIF 
TEMP3  =  0. 

ENDIF 

450  CONTINUE 

IF(  TEMP4  .GT.  0.)  THEN 
TEMPS  =  TEMP5  +  TEMP4 
TEMP4  =  0. 

ENDIF 
460  CONTINUE 

WRITE(UNIT=9,FMT=4e9)  TEMP5 

469  FORMATC/'  total  DELAY  FOR  ALL  CARGO  IS  ',F9.2) 

RETURN 

END 


I  v  I 


Appendix  F.  Description  of  SLAM  Code  and  FORTRAN  Inserts 


The  SLAM  Code.  Full  description  of  control  statement  (e.g.,  GEN,  LIMITS, 
NETWORK)  functions  is  beyond  the  scope  of  this  research.  For  a  detailed  expla¬ 
nation,  see  (18:796-802).  Other  than  the  control  statements,  much  of  the  SLAM 
code  provided  in  Appendix  D  is  repetitive  in  nature.  These  CREATE  and  QUEUE 
portions  form  the  bulk  of  the  code,  while  the  remaining  code  is  responsible  for  the 
simulation’s  activities. 

The  CREATE  portions  of  the  code  arc  used  for  supplying  the  simulation  with 
the  units  of  cargo  and  aircraft  which  will  perform  activities.  These  CREATE  portions 
also  suj)[)ly  the  attribute  information  about  the  entities  which  is  known  prior  to  their 
injection  into  the  route  system.  Each  CRE/VTE  supplies  one  unit  of  cargo  or  one 
aircralt  flight.  Each  successive  unit  of  cargo  or  flight  to  be  supplied  is  done  by 
sending  a  copy  of  tlu'  previous  entity  back  through  the  CRE.ATE  function  at  the 
appro|)riat('  time  as  the  simulation  progress('s. 

I  he  01  El  h'  portions  of  the  code  simply  establish  file's  re])resenting  the  places 
where  cargo  can  be  located  at  atiy  point  in  time  (i.e..  at  an  airport  or  in  the  cargo 
hold  ot  a  plan(').  With  the  ('xception  of  units  of  cargo  which  are  DONE  with  their 
Journeys,  aircraft  perform  all  actions  <luring  simulation  operation  and  cargo  is  stuck 
in  airports  (a.k.a..  El  E.-i)  until  actc'd  upon  by  a  plane'. 

I  Ilf  I'ORTR  AS  in.'ifris.  1  In*  FOIL!  K, AN  coele  for  the  SL.AM  simulation  in 
•Appendix  F.  provides  foi'  a  number  oi  functions  which  the  .SL.AM  language  does  not 
diie'clly  pro\  ide.  The  re’ason  for  many  of  the.se  I'OHTH.AN  insert  functions  revolve's 
around  the  SLAM  s  inability  to  directly  acce'ss  aiul  change'  t  !u'  attribute'  value's  e>f 
two  elilforent  fyjee'  ne'twoik  e'utitie's  at  the'  same'  time'.  As  a  re'sult,  most  e)f  t  lie’se' 
funetions  invoKe'  the'  lile  manipulations  re'e|uire'<l  te)  pass  infe)rmat ion  from  aireiaft 
feoanle'd  bv  caigo  to  the  uuit*^  oi  <arge). 


Some  [unctions  allow  for  direct  access  of  tlie  information  from  the  five  data  files 
required  [or  simulation  operation.  Certain  functions  are  designed  to  quickly  calculate 
and  provide  information  at  the  SLAM-level  which  is  used  for  other  purposes.  (For 
instance,  the  calculation  of  the  amount  of  time  required  for  ground  activities  at 
a  stop  is  determined  from  the  aircraft’s  attribute  information,  and  reported  back. 
I'he  SL.4M  code  then  keeps  the  aircraft  grounded  for  this  period  of  time.)  Other 
[unctions  provide  the  specialized  output  required  for  the  purposes  of  this  research. 

1  he  FORTRAN  program  reproduced  in  .Appendix  R  is  divided  into  the  fol¬ 
lowing  sections  or  subroutines:  MAIN  establishes  COMMON  storage  locations  for 
information  required  throughout  the  entire  SL.AM  and  FOIFJ'R.AN  code  and  CALLs 
the  SLA.M  |)rocessor  to  run  the  simulation:  INd'LC  sets  up  tlu'  iiq)ut  and  output 
[lies  reqiTnx'd.  HNADs  the  data  from  four  input  liles,  and  inserts  this  data  into  the 
common  variabh's  already  established  by  .M.AIN;  i'iiVENT  provides  the  FORTR.AN 
and  SLAM  processing  instructions  necessary  for  the  activities  shown  in  Figure  3.2: 
1  'SFHf  [unctions  allow  quick  calculation  of  iidormation  n-quired  at  the  ShAM  level; 
0  IFF!  takes  care  ol  the  final  instructions  ne(»ded  to  complete  tin'  simulation  pro¬ 
gram.  siicli  as  closing  of  o|ren<'d  T’OR'TRAN  files;  IdfCkS  and  (^I)FL.■'\^’  jirovich'  the 
instructions  lor  the  spixialized  r(‘ports  showing  th<'  cargo  onboard  each  [light  leg  and 
t!i('  amount  ol  cargo  delay  e,\[)eri<'nc(xl,  respectively. 

The  M.MN  progratn  actually  runs  the  enl io' simulation  and  information  estab¬ 
lished  t  hen'  has  import  ant  conse(|uenc<'s.  'I  he  amount  (»[  computer  meinorv  allocated 
lor  Si.A.M  |)rocessing.  which  is  critical  to  simulation  operation,  is  est ablislu'd  by  set¬ 
ting  the  "NSf,  i  and  "QS!',  T"  dimensions  (See  (  1S:3S!)  .3!)t))  ).  TIk- numbei- of  (light 
and  cargo  attributes  (17  and  !)S.  respi'cl  i  velv )  is  stoi'e<l  lor  subs<'(|uent  us('  b\'  (jther 
snbrout  ines  in  I'ORlltAN  /FT  luop  si'a  relies.  T  inally, \ariables  est  ablislu'd  in  .M.Al.N 
I  MS  I  A  1  S  aiui  I'.S  I  .A  TS)  deterinine  t  lu'  specific  i  inu'  |)eno<l  wit  bin  t  he  siniulat  ion  for 
\vlncli  results  are  to  lu'  <leterniined.  Setting  the  (irst  \'ariable  at  a  time  other  than 
/ere  ('-.i.’..  forces  the  snnulation  te>  progn'ss.  with  cargo  flowing  through  the 


systt'in.  before  delay  information  is  obtained.  Setting  tlie  second  variable  prior  to 
the  end  of  the  multiple-month  flight  schedule  (e.g.,  setting  KSd’ATS  equal  to  1440., 
('ven  though  a  three-month  schedule  will  continue  until  2160  hours  are  completed)  al¬ 
lows  the  simulation  to  continue  providing  new  cargo  supplies  as  results  are  obtained, 
rids  circumvents  problems  which  might  occur  by  itdtially  operating  the  simulation 
without  cargo  flowing  or  operating  the  simulation  as  if  the  supply  of  new  cargo  were 
suddeidy  stopped.  4'hese  two  variables,  which  impact  other  subroutines,  allow  the 
simulation  to  obtain  information  only  ap])licable  to  one  mouth’s  operations.  The 
remaituh'r  of  the  discussion  focuses  on  the  other  l‘X)bTIT'\N  rotitines. 

Hesid('  establishing  input  and  output  file^.  I.X4  bC  /f/rX/A;  data  and  stores 
iuh-rmat  ion  into  b'OM/V/OA’ storage  locations  for  access  by  ot  her  subroutines.  One 
of  th<'S(’  matric('s  of  information  is  the  cargo  demand  mat  rix.  Since  cargo  is  assumed 
to  arriv('  for  delivery  in  one-ton  units,  the  tonnage  of  cargo  dcunanded  in  the  hie  is 
conv('rted  to  a  rate  at  which  each  one-ton  unit  arrives.  'Fids  calculation  divides  the 
tonnage  for  ('axh  0-1)  pair  by  the  number  of  liours  in  a  month  (i.e.,  720).  When 
iis<'d  later,  the  demand  matrix  provides  the  number  of  hours  Ix'tween  the  arrivals 
of  each  one-ton  (\idt  of  cargo.  'Fhe  O'FTl'T  svd>routine  merely  directs  computer 
processing  to  the  LKOS  and  QDE1>.AY  subroutiiu's  and  closes  files.  The  remainder 
of  lliis  ('Xi)lanation  of  the  FOIFFR.AN  code  focuses  on  the  TSERF  functions,  the 
FA  l',N  1  routine's,  and  tinally  tlu-  LEOS  and  QDEEAY  output  routines. 

I’rilsker  metes  ihat  I'SERl’  functions  are'  ])ar1  icularly  useful  feir  situatiems 
wlmre  activity  durations  are  lea.se'el  upeeii  ('iitity  attribute's  (I8:2!)8  29!)).  For  this 
simulation.  ,tll  time's  asseee  iaie'd  with  aireraft  flights  are'  of  this  form.  Fhe  time'  at 
whie  h  each  uidt  of  e  argee  is  supplie'el  eh'jx'nels  on  the'  elemanel  leer  each  ()-D  pair,  le) 
proe  ide  the-se-  time's,  the-  ESERF  fune  tieeiis  ix'rfeuni  the'  folleewing  actieuis: 

I.  Fhe  (  7i’/' 4 /7','SF.\M  staie'inent  supplying  t he' aircraft  Night  e'lit ity  de)e's  met  ,  in 
e'sse'iie  e'.  t  7f/.'.4  77',’ flight s.  File'  t  77 /'.’,4 /'/•,’ stale'me'iit  su])plie's  a  eluminv  entity 
whose'  subse'e|ue'nt  ae'tieens  are'  eh'te'rmine'el  threeiigh  the'  I  SI\IU‘'(I}  state'ine'ut. 


By  making  a  copy  of  this  dummy  entity  and  sending  the  copy  back  through  the 
CREATE  statement,  subsequent  calls  to  the  USERF  function  are  made,  until 
the  USERF  function  determines  that  the  supply  of  flights  has  been  exhausted. 
Thus,  the  supply  of  flights  really  comes  from  the  first  USFiRF  function.  The 
SLAM  code  only  really  needs  to  know  how  long  to  hold  the  dummy  entity 
before  allowing  it  to  proceed  to  the  next  activities  (i.e.,  departing  on  the  first 
leg  and  going  back  through  the  CREATE  sequence).  This  USERE(l)  function 
accomplishes  the  following  actions: 

•  First,  a  flight’s  attributes  are  established  by  REAEhwg  a  set  of  data  values 
stored  in  t  he  flight  schedule  file  (See  Appendix  Q).  The  attribute  values 
correspond  directly  with  the  fields  of  information  provided  in  this  file, 
created  by  the  FORTRAN  scheduling  programs. 

•  Second,  a  count  is  maintained  of  the  number  of  flights  whose  attributes 
have  been  READ  (a.k.a.,  the  number  of  flights  departing). 

•  Finally,  the  function  calculates  the  time  between  the  current  simulation 
time  and  the  time  when  the  (light  needs  to  depart  (i.e..  field  9).  I'he  time 
calculated  is  reported  to  the  SLAM  code,  which  will  not  do  anything  with 
the  cntity(ies)  until  this  amount  of  time  has  elapsed. 

2.  ddie  VSERE(2)  function  looks  though  an  aircraft’s  attributes  for  the  time 
recpiired  to  fly  to  the  next  location  (i.e.,  fields  10,  13,  ...,  36)  based  (ui  where 
th<'  aircraft  is  currently  stopped  (i.e.,  field  7). 

•3.  I'he  /  'SERl''(2)  function  simply  determines  the  numerical  representation  of  the 

air|)ort  where  the  aircraft  currently  is  located  (i.e.,  fields  8.  1  1 .  17).  based 

on  the  current  stop  number  (i.e.,  field  7). 

1.  The  VSI‘'RI''(D  function  looks  through  an  aircraft’s  attributes  for  the  ground 
tinu-  (i.e.,  fields  9,  12.  ...,  30)  applicable  to  the  current  sto[)  number  (i.e..  field 
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5.  Ail  the  cargo  CREAl'E  portions  of  the  SLAM  code  use  the  last  function, 
USERF(5),  to  calculate  when  to  supply  the  next  unit  of  cargo  of  the  ap¬ 
plicable  type.  When  these  times  are  requested,  SLAM  has  direct  access  to 
the  attributes  of  a  cargo  unit;  therefore,  this  is  the  only  USERF  function  not 
based  on  aircraft  attribute  values.  This  function  is  simply  a  table  look-up  of 
information  stored  in  the  demand  matrix,  based  on  which  0-D  pair  of  cargo 
(i.e.,  fields  2  and  3)  is  involved. 

Before  disr\^s‘.;ing  th^'  FORTRAN  E\  ENTs>^  an  explanation  of  the  TEMP 
QUEUE  alleviates  the  need  for  separate  discussion  in  each  EVENT  description  which 
follows.  Because  the  HOLD  Q Ei' E  siores  all  cargo  onboard  all  aircraft  and  each 
airport  QUEUE  stores  all  cargo  at  a  particular  location,  computer  searches  through 
these  files  might  become  cumbersome.  For  this  reason,  a  TEMP  QUEUE  has  been 
utilized  to  limit  the  number  of  computer  search  operations  which  might  be  required. 
For  each  search  through  a  fde  (a.k.a.,  QUEUE),  each  unit  of  cargo  is  removed  from 
the  current  file  location  and  examined.  When  the  unit  of  cargo  fulfills  certain  cri¬ 
teria,  the  attributes  of  the  cargo  might  be  changed.  When  the  criteria  are  not  met. 
the  cargo  attributes  usually  remain  intact.  In  either  case,  the  cargo  is  either  hied 
temporarily  in  the  1  l‘'MP  QUEUE  or  refiled  in  a  QUEUE  other  than  the  one  cur¬ 
rently  being  searched  through.  This  forces  the  computer  to  examine  the  units  of 
cargo  in  the  file  one  at  a  time,  until  all  cargo  in  the  HOLD  ov  airport  QUEV E  hns 
been  exaniined.  After  all  units  of  cargo  have  been  examined,  all  units  of  cargo  hied 
in  the  77',WF  QUElH'Mue  remo\ed  and  rehled  back  in  the  original  hie  searched. 

Afso,  to  eliminate  confusion  of  the  method  used  for  comparing  the  attribute 
\alu('S  of  aircraft  and  cargo,  understanding  of  certain  SL.A.M  peculiarities  may  be 
helpful.  SL.AM  can  normally  only  access  the  attribute  vahies  of  one  entity  at  a  time, 
through  the  ".'\THIB'’  array.  For  this  re,sea.rch,  the  attribute  values  available  in  this 
".'VrUlB"  array  usually  lielong  to  an  aircraft  flight  eti*’*^ies.  SL.A.M  provides  subpro- 
grmri.;.  u.:.e<i.b.e  at  the  fOlt  I'll .\N-in.sert  level,  which  can  access  and  ehang('  attribute 


values  of  an  entity  other  than  the  entity  currently  being  processed  through  a  SLAM 
statement.  Much  like  this  research’s  use  of  the  temporary  QUEUE  ]\isi  discussed, 
SLAM  can  temporarily  copy  an  entity’s  attributes  into  another  array,  similar  to  the 
“ATRIB”  array.  The  second  entity’s  attributes  can  thus  be  accessed  and  changed, 
when  recpiired,  by  placement  of  the  values  into  the  other  array,  and  storing  the  other 
array’s  values  into  files  when  required.  SLAM  already  has  predefined  subprograms 
which  perform  these  functions.  “Subroutine  RMOVE(NRANK,  IFILE,A)  removes 
an  entry  with  rank  NRANK  from  file  IFILE  and  places  its  attributes  into  the  buffer 
array  A”  (f 8:297).  “Subroutine  FILEM(IFILE,A)  files  an  entry  with  attributes 
specified  in  the  liuffer  array  A  into  file  IFILE)”  (18:297).  The  computer  instructions 
through  which  this  research  makes  comparisons  between  flight  and  cargo  attributes 
relies  heavily  on  SLAM  subprograms  like  these. 

The  last  important  aspect  relating  to  activities  occurring  during  a  flight’s  pro¬ 
cessing  through  th('  EVENTs  relates  to  time.  Simulation  clock  time  stands  still  as 
eacli  EVENT  is  processed.  The  only  activities  which  take  time  are  flying  and  sitting 
on  tlie  ground.  With  thes<'  general  aspects  in  mind,  a  discussion  of  each  EVE.NT 
follows. 

During  the  FILL  E\  ENT,  tlie  flOUD  \s  searched  for  all  cargo  identified  as  cur¬ 
rently  residing  on  the  aircraft  which  is  about  to  depart  on  a  flight  leg.  For  each  unit 
of  cargo  found  onboard  the  aircraft.,  a  search  of  the  cargo  entity’s  attributes  deter¬ 
mines  tlie  next  .si't  ot  attribute  fields  wliidi  have  not  yet  been  filled.  1  iiese  attribute 
fields  are  now  filled  in,  telling  the  cargo  that  their  journey  is  about  to  continue. 
Figure  F.l  shows  how  tlu'se  searches  and  file  manipulations  are  accomplished. 

riie  simulation  do<’s  not  impiiciily  know  where  each  |)lane  is  located  at  every 
instant  in  time,  for  this  reason  several  /fl7W7’s,  including  /LYL’ IF  first  determine 
tin'  airport  where  the  aircraft  is  currently  located.  This  E\  EN  T  is  snecifi'  ally  fle- 
signed  to  /7cku|)  A’A'IL  cargo  at  the  current  air|)ort,  when  aircraft  space'  allows.  To 
pickup  cargo,  a  se'arch  looks  through  all  cargo  curix'iitly  located  at  tlu'  airport  lor 
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Figure  F.l.  The  FILL  EVENT 


cargo  for  which  the  decision  rules  indicate  pickup  is  appropriate.  A  unit  of  cargo 
must  need  to  travel  in  the  same  direction  as  the  aircraft.  The  cargo  must  either  not 
require  a  specific  type  of  mission  or  require  the  type  of  mission  to  which  the  flight  is 
assigned.  If  these  criteria  are  met,  the  cargo  is  placed  onboard  the  aircraft  (i.e.,  filed 
in  the  HOLD),  after  the  cargo’s  attributes  are  updated  with  the  information  needed 
to  document  the  next  segment  of  the  cargo’s  journey.  If  the  criteria  are  not  met,  the 
unit  of  cargo  remains  at  the  airport  until  another  aircraft  can  pick  it  up.  No  other 
FA  'ENT?>  assign  cargo  to  aircraft. 

•Just  before  arrival  at  a  stop,  the  SLAM  ASSIGN  statement  increments  the 
stop  number  (i.e.,  field  7)  of  the  aircraft  flight  entity.  Without  this  statement,  the 
aircraft  (and  sub.sequently  the  cargo  onboard)  would  not  know  of  arrival  at  the 
ne'xt  airport  along  the  route.  Thus  when  the  computer  processes  a  flight  through 
tlu'  DRO^^  ^-  VDNT,  the  jlyiiig  activity  is  done  and  determination  must  be  made 
"■bet  her  to  drop  cargo  .it  tills  iiou  airport.  Each  uu''  ol  cargo  is  removed  trom  the 
HOLD  to  find  the  cargo  on  the  specific  plane.  For  all  cargo  on  the  aircraft,  the 
origin,  destination,  and  time  at  which  the  cargo  first  got  on  the  aircraft  are  stored  in 
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a  temporary  working  file,  as  long  as  the  flight’s  arrival  falls  within  the  information 
gathering  window  (i.e.,  between  BSTATS  and  ESTATS  discussed  previously).  This 
provides  a  manifest  listing  of  all  cargo  on  the  aircraft  during  the  flight  leg  just  flown. 
I  ke  computer  updates  each  unit  of  cargo’s  current  location  attribute  (i.e.,  field 
7),  informing  the  cargo  of  arrival  at  the  new  location.  When  the  current  location 
matches  the  cargo  destination,  the  cargo’s  journey  is  completed,  so  the  cargo  is  now 
(fded  in)  DONE.  Otherwise  the  cargo  remains  on  the  aircraft  until  further  offload 
criteria  can  be  applied  —  remember  that  no  time  elapses  between  the  beginning  of 
the  DROP  and  the  conclusion  of  the  FEIN  EVENls.  The  decision  logic  associated 
with  the  PNEW  EVENT  is  shown  in  Figure  F.2  and  the  DROP  EVENT  is  shown 
in  Figure  F.d. 


iMgnre  F.-l.  f  he  DROP  EVEN  1' 


Hetore  decisions  can  be  made  wliether  cargo  should  remain  onboard  an  aircraft, 
the  aircraft  direction,  as  well  as  the  cargo  direction  and  mission  needs,  must  reflect 
the  current  location.  The  FDIR  and  COIR  EVENTs  provide  tliese  updates  to  flight 
and  cargo  attributes.  The  FDIR  T’V'£’,V7’ simply  supplies  the  direction  of  a  flight’s 
ne.xt  leg.  .As  the  operations  occurring  in  CDIR  are  more  complex,  the  activity  flow 
is  shown  in  Figure  F.4.  As  can  be  seen  from  Figure  F.4,  the  entities  processed 
through  this  EVENT  are  aircraft,  eve.;  though  only  cargo  attributes  change.  Cargo 
found  onboard  the  particular  flight  have  their  mission-to-get-on-flag  and  direction 
attributes  updated,  based  on  th<'  current  location  (previously  adjusted  during  the 
DROP  EVEN'T).  Both  the  EDIR  and  CDIR  FV  l-L\  T?,  access  information  READ  'm 
during  the  /;V77./C  initial  subrout  iiu*. 


Figure  F.4.  ddie  CDIH  FVFNT 


4  h('  DOFE  EVEN  r.  showi\  in  Figure  F.5,  decide.s  whether  cargo  should  remain 
oid)oard  an  aircraft  which  has  arrivi'd  at  a  new  location.  1  his  entire  E\  EN  I'  ]s 
sl-;ip[)cd  when  an  aircraft's  current  locat  ion  is  t  he  same  as  t  he  home  base  I  he  flight 
is  tinished.  .After  determining  the  curnuit  location  from  the  aircraft  flight  attributes, 
examination  of  cargo  onboard  all  aircraft  (a.k.a..  filed  in  the  HOLD)  pidls  out  all 
units  on  the  s[)ecific  flight.  For  tlu'se  units  of  cargo  to  stay  on  the  flight,  the  flight's 


direction  must  match  the  cargo  direction;  and  the  cargo  must  ei<  lier  not  require  a 
specific  mission  or  the  flight’s  mission  must  be  one  which  the  cargo  needs  for  travel 
further  along  its  journey.  When  this  criteria  fails,  the  unit  of  cargo  is  dropped  at  the 
location  (a.k.a.,  fderl  in  the  appropriate  airport  QUEUE)  to  await  transshipment  on 
another  flight. 


figure  f’.o.  I  he  DO  If’  f’A  KN'l 


I'A'crv  flight  <'\(’iituall\'  comph'ting  its  mission  and  returning  to  its  honu'  l)as(' 
might  have  cargo  onboard.  Sinc('  the  flight  t<'rminates  at  tlu’  hom<’  l)as('  airport,  all 
(argo  (  arried  must  be  offloaded  to  await  another  flight.  I'he  /•'/■/.V  de|)icted 

in  figure  f.li.  handh's  t  hese  situations,  d'he  com|)uter  skii)s  this  /'.’l/'.V/’ when  the 
an  j)ort  location  is  not  the  honu’  base.  Kach  unit  of  cargo  found  onboard  (a.k.a..  fih'tl 


in  the  HOLD)  the  sp('eihr  aircraft  are  offloaded  a.t  the  airport  (a.k.a..  refih’d  in  the 
airport  QUEUE). 


Figure'  !•  .6.  The  FFIN  FVFNT 


I'he  |)ievi<uis  I'lVUS'E  (along  with  the  SLAM  57 '/’and  /'Y,  Tact  i  vit  ies)  describe' 
the-  e'titire'  seepiene-e'  of  eve'iits  applicable  to  processing  aire  raft  flight  e'litities  through 
the-  simulatieen.  One  more  /fr/bVy' affects  cargo  entitie's  prieer  to  the'ir  e'liininat ie)n 
from  the  netwe)rk.  d’his  ('.AHGo  EVENT  atovos  the  information  about  every  unit  of 
cargee’s  jeeurne'v  into  a  temporary  working  file.  For  eaedi  se'gment  of  a  cargo  entity's 
jeiuiiie'y.  a  re'ce)rel  is  ke'pt  eef  the-  cargo’s  origin,  the'  cargei's  eh'st inatie)n.  the'  mmdie'r  eef 
the  (light  take'll  e)n  the’  se’gment.  the  tail  number  taken  e)n  the  se'gme'iit.  the  karat ieen 
wlie're'  ste)|)pe'd.  the'  time’ departe’el  the  last  stoj),  the  t ime  eleparteel  the  current  steep, 
and  the'  time'  e-lapseel  (a.k.a..  the  elelay  e.xperienced)  on  the  se'gment.  This  file  will 
only  eeentain  information  ajeielieable  to  the  time  period  within  which  results  are  to 
be-  obtaineel  (i.e..  within  BST.A'FS’  and  fvSdVVl’S).  Fnits  of  carge)  eompleting  their 
jeeurne'vs  in  t  he'  applie  able’  iid’ormation-gathering  window  may  have  t  raveleel  on  flights 
prior  t o  t  hat  t ime'. 


I  lie  out  put  suhroutiue  looks  llirougli  the  temporary  file  for  aircraft  aiui 

consolidates  the  information  applicaWh’  to  each  individual  flight  leg.  The  consoli¬ 
dation  groups  all  cargo  (uitities  (on  each  specific  flight  h‘g)  having  the  same  origin, 
destination,  and  time  jnit  onboard.  1  ht'  sidiiauitine  thus  provides  information  about 
how  much  of  the  aircraft 's  cajiacity  has  bi-en  utilized  on  each  flight  and  what  specific 
cargo  were  onboard  for  (vich  cargo  grou|)  the  (aitj)ut  shows  the  total  number  of 
cargo  units  which  share  tlu'  same  origin,  destination,  and  time  onboard.  Tlu'  out¬ 
put  provides  a  synopsis,  by  flight.  ol  the  cargo  groups  onboard.  These  results  are 
(  a[)t lin'd  in  an  output  file,  an  ('.xcerpi  of  whiili  is  provided  in  .Appc'iidix  S. 

1  he  output  subroutine  QD/'/.A)  grou|)s  information  in  a  manner  similar  to 
the  A /'.V  I'.S' subrout  i  lie.  ()ni.l.\\  uses  the  inlormation  stored  in  the  teni])orary  fih' 
lor  cargo  historn's  to  deti'rmiue  the  di'lay  ('xperii'iiced  by  all  cargo  entiti 's  within 
t  h('  t  ime  pericxi  for  obtaining  n'sults.  1  he  smallest  group  depicted  are  tliosi'  units 
of  cargo  ol  the  same  0-1)  pair,  on  the  same  flight,  at  the  same  stop  location,  which 
hav(' ('XperieiKS'd  t  he  same  amount  oi  <lelay.  dlie  0/)/',’A.I  T  siibrout  iiie  subt  ot  als  the 
delay  experienc  ed  at  each  airport  and  totals  tlu'  overall  delay  exiierience  for  c-ac  ii 
0  1)  cargo  pair.  I  hc  results  obtained  from  this  siibroii'ine  are  stoical  in  another 
output  fih’.  .\p|)endix  U  is  an  c'xcc'ipl  cd  an  example  fih'. 
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Appendix  G.  The  BASE. IMP  File 


riiis  Hie  provides  a  listing  of  all  airports  encompassing  the  route  system  -  all 
airports  may  lu't  be  visited  in  any  given  montli.  A  computer  associates  a  number 
witli  each  ot  the  International  Civil  Aviation  Organization  (ICAO)  airport  codes,  in 
the  order  listed  in  the  file.  Ihtln'r  mmu'rical  or  ICAO  representations  can  be  used  to 
refer  to  specihe  airports.  In  tlu'  ('xainph'  below,  airport  1  and  airport  A  AAA  would 
be  synonymous.  'The  IC.AO  cod('s  herein  were  made  up  for  the  hypothetical  twelve- 
airport  rout*'  system;.  I  bis  inp:  t  file  is  reepiired  for  MAC’s  FORTRAN  scheduling 
program  found  in  .■\|)p(Mulix  ;\.  I  he  file  follows: 


AAAA 

BBBB 

CCCC 

DDDD 

EEEE 

FFPE 

GGGG 

HHHH 

nil 

JJM 

KKua 

LLLL 

MMMM 

NNNN 

0000 

rppp 


Appendix  H.  The  ROUTE. INP  File 


This  file  describes  all  routes  which  will  be  used  for  the  month,  as  would  be 
determined  by  the  MAC  computer  channel  route  model’s  linear  programming  relax¬ 
ation.  Each  route  is  listed  on  a  separate  line  with  airport  ICAO  codes  and  numerical 
rea.son  for  stopping.  The  order  in  which  routes  are  listed  in  the  file  implicitly  as¬ 
sociates  a  route  with  a  mission  number.  The  routes  depicted  herein  were  used  for 
tl;<'  hypothetical  twelve-airport  route  system.  This  input  file  is  required  for  MAC’s 
schedule-creation  program  found  in  Appendix  A.  The  iile  follows: 


AAAAl  CCCC6  IIII6 
AAAAl  DDDD6  KKKK6 
AAAAl  FFFF6  AAAA9 
BBBBl  AAAA4  BBBB9 
BBBBl  AAAA4  FFFF6 
BBBBl  CCCC6  BBBB9 
BBBBl  DDDD4  FFFF6 
mil  GGGG4  EEEE6 
mil  HHHH4  JJJJ4 
mil  JJJJ4  HHHH4 
mil  KKKK4  FFFF6 
KKKKl  FFFF6  CCCC4 
KKKKl  IIII4  GGGG4 
KKKKl  LLLL6  FFFF6 


EEEE6  AAAA9 
DDDD6  AAAA9 


BBBB9 

EEEE4  BBBB9 
DDDD4  CCCC6  11119 
11119 
11119 

DDDD4  GGGG6  11119 
DDDD6  EEEE4  KKKK9 
HHHH6  JJJJ4  KKKK9 
11114  KKKK9 


Appendix  1.  The  GNDTM.INP  File 


This  file  tells  the  nuinber  of  flights  required  for  each  mission  and  the  type 
of  aircraft  used  for  these  flights.  I'he  MAC  computer  channel  route  model’s  linear 
programming  relaxation  normally  provides  this  information.  The  first  figure  on  each 
line  is  the  number  of  flights,  and  the  second  figure  is  the  aircraft  type.  In  the  example 
below,  eight  flights  of  mission  one  would  be  required,  and  these  missions  would  be 
flown  using  C-5  (i.e.,  type  1)  aircraft.  The  figures  appearing  herein  were  for  the 
hypothetical  twelve-airport  route  system.  This  input  file  is  required  for  the  two 
schedule-creating  programs  found  in  Appendices  A  and  B.  The  file  follows: 


8  1 

4  1 

24  1 

6  2 

43  2 

20  2 

8  2 

10  3 

10  3 

10  3 

10  3 

12  2 

12  2 
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Appendix  J.  The  GNDTM.INP  File 


This  file  gives  the  amounts  of  time  required  by  the  various  ground  activities  for 
which  a  plane  stops  and  the  aircraft  cargo  capacities,  by  aircraft  type.  The  columns, 
except  the  last,  coincide  with  numerical  codes  designating  the  reason  for  stopping: 
the  first  is  for  mission  commencement,  explaining  why  zeroes  are  found  in  the  entire 
column;  the  next  two  are  for  onload  and  offload  times,  respectively;  the  fourth  and 
fifth  are  the  time  for  enroute  fuel  and  aircrew  change;  enroute  crew  rest  time  is  in 
the  sixth  column;  the  seventh  and  eighth  columns  are  not  currently  used.  The  last 
column  provides  the  number  of  one-ton  cargo  payloads  which  a  type  of  aircraft  can 
hold.  The  lines  of  data  provide  the  information  applicable  to  C-5,  C-141,  C-130. 
DC-S,  DC- 10.  B-717.  and  C-17  aircraft  —  in  that  order.  Programs  refer  to  aircraft 
type  by  the  order  listed  in  this  file.  Thus,  a  C-5  is  aircraft  type  1.  a  C-141  is  aircraft 
2,  and  so  on.  The  figures  appearing  were  provided  by  HQ  MAC/XPYR  and  were 
used  intact  with  the  hypothetical  twelve-airport  route  system.  This  input  file  is 
required  for  the  two  FORTR.AN  schedule-creating  programs  found  in  Appendices  .A 
and  B.  I'he  file  follows: 


0 

4.25 

4.25 

4.25 

4.25 

18.25 

4.25 

4.25 

50 

0 

3.25 

3.25 

3.25 

3.25 

17.25 

3.25 

3.25 

20 

0 

2.25 

2.25 

2.25 

2.25 

16.25 

2.25 

2.25 

7 

0 

3.00 

3.00 

3.00 

3.00 

16.00 

3.00 

3.00 

25 

0 

4.00 

4.00 

4.00 

4.00 

16.00 

4.00 

4.00 

40 

0 

4.00 

4.00 

4.00 

4.00 

16.00 

4.00 

4.00 

71 

0 

3.25 

3.25 

3.25 

3.25 

17.25 

3.25 

3.25 

32 
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Appendix  K.  The  FLY. DAT  File 


The  flying  times  between  locations  are  in  this  file.  Each  row  of  data  includes 
a  takeoff  location,  a  landing  location,  and  the  time  to  fly  between  the  points.  HQ 
MAC/XPYR  uses  flying  times  based  on  historical  experience.  For  the  hypothet¬ 
ical  twelve-airport  route  system  the  times  shown  below  were  used.  These  times 
approximate  the  times  used  by  HQ  MAC/XPYR.  This  input  file  is  required  for  the 
two  FORTRAN  schedule-creation  programs  found  in  Appendices  A  and  B.  The  file 
follows: 


1  2  1.10 

1  3  7.90 

1  4  7.80 

1  6  7.90 

2  1  1.10 

2  3  8.20 

2  4  7.50 

2  5  7.70 

3  2  9.70 

3  1  9.40 

3  5  1.40 

3  4  1.60 

3  6  1.40 

3  9  6.20 

4  1  8.70 

4  3  1.80 

4  5  0.70 

4  6  2.10 

4  7  2.20 

4  9  3.30 

4  11  4.00 

5  1  9.10 

5  2  8.70 

5  3  1.70 

5  4  1.20 

5  6  2.50 

5  9  3.10 

5  11  4.20 

6  1  9.90 

6  2  10.40 

6  3  1.50 

6  4  1.80 

6  5  2.50 


K-1 
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0. 
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11 
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Appendix  L.  The  ROUTE.DAT  File 


As  this  file  provides  the  foundation  upon  wliich  the  detailed  flight  schedule  is 
based,  this  file  deserves  special  description. 

The  number  of  lines  included  for  each  mission  depends  upon  how  many  tail 
numbers  will  be  assigned  for  flying  the  number  of  flights  for  each  mission  type, 
along  with  the  number  of  airport  locations  where  these  aircraft  stop.  Each  line 
of  information  breaks  down  as  follows:  a  tail  number,  a  stop  number,  the  airport 
number  stopped  at,  a  time,  and  the  mission  number  to  which  the  tail  number  is 
assigned. 

The  number  of  lines  for  each  tail  number  ties  directly  to  the  number  of  places 
stopped  at  for  the  mission  type,  as  defined  in  the  route  file.  For  the  route  AAAAl 
BBBB6  AAAA9,  each  tail  number  flying  this  route  will  have  three  lines  in  this  file  — 
one  for  stopping  at  (departing  from)  airport  1,  one  for  stopping  (resting)  at  airport 
2,  and  one  for  stopping  (ending  up)  at  airport  1. 

The  times  listed  in  the  file  serve  two  purposes.  The  time  listed  on  a  tail 
number’s  first  line  provides  the  time  during  the  month  (i.e.,  a  720-hour  period  of 
time)  when  that  tail  number  departs  on  its  first  flight.  (.After  establishing  the  first 
takeoff,  this  time  becomes  irrelevant.)  The  times  listed  for  a  tail  number’s  subsequent 
lines  provide  the  amount  of  time  the  aircraft  will  remain  on  the  ground  until  taking 
off  again.  Of  particular  note  is  the  time  listed  on  a  tail  number’s  last  line  (i.e., 
mission  stopping  back  at  the  liome  base).  This  time  is  the  ground  time  until  the 
next  flight  for  that  particular  tail  number  commences. 

As  defined  in  this  schedule,  each  tail  number  would  fly  the  route  repeatedly, 
as  long  as  a  simulation  program  would  allow  time  to  proceed. 

The  information  shown  in  the  file  l)elow  were  u.sed  for  the  hypothetical  twelve- 
airport  route  system.  This  type  of  file  is  directly  output  from  MAC’s  schedule- 


creation  {)rogiarn  found  in  Appendix  A.  This  file  also  serves  as  i 
schedule-creation  program  found  in  Appendix  B.  The  file  follows 
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Appendix  M.  The  FDIRCT.DAT  File 


This  file  provides  directional  guidance  associated  with  each  flight  leg.  Each 
line  of  the  file  provides  directional  guidance  for  one  route.  The  first  number  is  the 
direction  of  travel  on  the  first  flight  leg;  the  second  number  is  direction  on  the  second 
leg,  and  so  on.  Twelve  flight  legs  are  allowed  per  route. 

The  directional  codes  in  this  research  were  “5,”  “10,”  and  “15.”  The  “5” 
represents  travel  in  one  direction,  while  the  “15”  represents  travel  in  the  opposite 
direction.  This  could  be  thought  of  as  representing  east  and  west,  for  instance.  The 
“10”  represents  a  neutral  direction,  which  allows  the  placement  of  cargo  on  aircraft 
going  in  either  direction.  The  program  user  must  establish  directional  codes  which 
adequately  describe  the  route  system  in  use. 

The  figures  appearing  herein  were  used  for  the  hypothetical  twelve-airport 
route  .system.  This  input  file  is  required  for  the  schedule-creation  program  found  in 
.Appendix  ('  and  for  the  SLAM  FORTRAN  insert  program  found  in  .Appendix  E. 
The  file  follows: 


5.  5.15.15.00.00.00.00.00.00.00.00.00. 
5.  5.15.15.00.00.00.00.00.00.00.00.00. 
5.15.00.00.00.00.00.00.00.00.00.00.00. 
10.15.00.00.00.00.00.00.00.00.00.00.00. 
5.  5.15.00.00.00.00.00.00.00.00.00.00. 
5.15.00.00.00.00.00.00.00.00.00.00.00. 
5.  5.15.15.00.00.00.00.00.00.00.00.00. 

15.15.15.15.  5.00.00.00.00.00.00.00.00. 
15.  5.15.00.00.00.00.00.00.00.00.00.00. 

5.15 .  5.00.00.00.00.00.00.00.00.00.00. 

5.15.15.  5.  5.00.00.00.00.00.00.00.00. 

15.15.  5.  5.  5.00.00.00.00.00.00.00.00. 

15.15.  5.  5.  5.00.00.00.00.00.00.00.00. 

5.15.  5.  5.00.00.00.00.00.00.00.00.00. 


M-1 


Appendix  N.  The  CDIRCT.DAT  File 


This  file  provides  directional  guidance  to  cargo,  ba^ed  on  the  cargo’s  current 
location  and  intended  destination.  Each  line  of  the  file  provides  direction  for  one 
location-destination  pair  —  not  to  be  confused  with  0-D  pairs.  The  first  number  is 
the  airport  number  where  the  cargo  is  currently  located.  The  second  number  is  the 
number  of  the  destination  airport.  The  final  number  is  the  direction  which  the  cargo 
needs  to  travel. 

The  directional  codes  currently  used  in  this  research  were  “5,”  ‘TO,”  and  “15.” 
The  “5”  represents  travel  in  one  direction,  while  the  “15”  represents  travel  in  the 
opposite  direction.  This  could  be  thought  of  as  representing  east  and  west,  for  in¬ 
stance.  The  “10”  represents  a  neutral  direction,  which  allows  the  placement  of  cargo 
on  aircraft  going  in  either'  direction.  The  program  user  must  establish  directional 
codes  which  adequately  describe  the  route  system  in  use. 

The  figures  appearing  herein  were  used  for  the  hypothetical  twelve-airport 
route  system.  This  input  file  is  required  for  the  SLAM  F'ORTRAN  insert  program 
found  in  Appendix  E.  The  file  follows: 
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Appendix  O.  The  CMSSIJN.DAT  Tile 


I'his  file  supjjlies  the  user-provided  decision  criteria  defining  which,  if  any, 
specific  .nissions  cargo  must  fly  on.  Tite  first  two  numbers  o^i  a  line  are  the  numerical 
re[)resentations  for  the  locaf ion-destination  pair.  The  other  three  numbers  specify 
which  missions  cargo  must  be  on,  or  wait  for,  from  the  current  location  to  reach  the 
destination.  When  all  three  mission  numbers  are  zero,  the  cargo  is  free  to  get  on 
any  available  mission  going  in  the  correct  direction. 

The  figures  a[)peariii"  herein  were  used  for  tiie  hypothetical  twelve-airport 
route  system,  l  or  another  system.  th(‘  user  would  need  lo  determine  whether  cargo 
must  travel  by  certain  tuissions  to  g<‘t  to  their  destination.  This  input  file  is  required 
for  t  lit'  Sb.\.\I  I'OIM  K.A.X  insm  t  program  found  in  .Appendix  E.  The  file  follows; 
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Appendix  P.  The  DEMAND.DAT  File 


This  file  supplies  the  tonnage  of  cargo  demand  for  0-D  pairs.  In  each  line  of 
data,  the  first  two  numbers  are  numerical  representations  of  the  origin  and  des¬ 
tination  airports.  The  third  number  is  the  quantity,  in  tons,  of  ca^-go  for  the 
origin-destination  pair.  The  figures  appearing  herein  were  used  for  the  hypothet¬ 
ical  twelve-airport  route  system.  This  input  file  is  required  for  the  cargo  simulation 
insert  program  found  in  ApiJondix  E.  Tiie  file  follows: 
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Appendix  Q.  Excerpt  of  SRAW1.DAT  File 


This  file  is  the  output  created  by  the  FORTRAN  flight  scheduling  program 
found  in  Appendix  B.  This  file  is  also  the  input  file  used  by  the  FORTRAN  program 
found  in  Appendix  C.  The  format  of  this  file  is  exactly  the  same  as  the  file  created  by 
the  FORTRAN  program  found  in  Appendix  C,  which  is  the  SCHED.DAT  file.  The 
SCHED.DAT  file  is  the  input  file  used  to  schedule  flights  for  the  SLAM  simulation 
found  in  Appendices  D  and  E.  An  excerpt  of  the  file  created  for  the  hypothetical 
twelv'e-airport  route  system  follows: 
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7 

10.: 

20. 

,  5, 

2. 

,  0.  2 

15.00 

1  7 

.50 

)  4 

3, 

25 

2 

.  10 

6. 

17. 

25 

2.50 

5. 

3.25 

8. 

70 

2. 

0. 

00 

0. 

,00 

0. 

0, 

.00 

0. 

00 

0. 

0, 

.00 

0. 

.00 

0 

0 

00 

0 

.00 

0. 

0, 

00 

0.00 

0. 

0.00 

0. 

00 

0. 

0. 

.00 

0. 

,00 

0. 

0 

.00 

0. 

,00 

0. 

0. 

.00 

0. 

,00 

0 

8 

8. 

11. 

7. 

15, 

9, 

.  0.  9 

1 , 

17.50 

1  1 

.70 

1  7 

2 

,25 

2 

.30 

5. 

16, 

25 

1.20 

4. 

2.25 

1. 

80 

3. 

16 

.25 

6, 

,20 

9. 

0, 

.00 

0. 

,00 

0. 

0, 

,00 

0, 

.00 

0 

0, 

.00 

0 

.00 

0. 

0. 

00 

0.00 

0. 

0.00 

0. 

00 

0 

0. 

00 

0, 

.00 

0. 

0. 

.00 

0, 

,00 

0. 

0. 

,00 

0. 

,00 

0 

9. 

9 

1 . 

12. 

7. 

15. 

9. 

,  0.  9 

1 . 

20.00 

1  0 

1.60 

1  8 

2 

.25 

0 

.9010. 

,  2, 

25 

0.80 

9. 

0.00 

0. 

00 

0. 

0, 

,00 

0, 

.00 

0. 

0 

.00 

0. 

.00 

0. 

0, 

.00 

0, 

.00 

0 

0 

.00 

0 

.00 

0. 

0. 

00 

0.00 

0. 

0.00 

0. 

00 

0. 

0, 

,00 

0, 

.00 

0. 

0 

.00 

0. 

.00 

0. 

0, 

,00 

0, 

.00 

0 

10 

.  10. 

13. 

7. 

5 

9 

.  0.  9 

1 . 

22.50 

1  0 

1.5010 

2 

.25 

1 

.00 

8. 

2 

25 

0.50 

9. 

0.00 

0. 

00 

0. 

0, 

.00 

0, 

.00 

0. 

0 

.00 

0, 

.00 

0. 

0. 

.00 

0. 

.00 

0 

0, 

.00 

0 

.00 

0. 

0, 

00 

0.00 

0. 

0.00 

0. 

00 

0. 

0. 

.00 

0 

.00 

0. 

0 

.00 

0. 

.00 

0. 

0, 

.00 

0 

.00 

0 

11 

.  11. 

14. 

7, 

5 

9 

.  0.  9. 

25.00  2 

:.  1011 

2 

.26 

5 

.20 

6. 

16 

25 

1.80 

4. 

2.25 

2. 

20 

7. 

16 

.25 

1 

.50 

9. 

0 

.00 

0, 

.00 

0. 

0, 

.00 

0 

.00 

0 

0 

.00 

0 

.00 

0. 

0 

00 

0.00 

0. 

0.00 

0. 

00 

0. 

0 

,00 

0 

.00 

0. 

0 

.00 

0, 

.00 

0. 

0, 

.00 

0, 

.00 

0 

Q  1 


5.  12.  7.20.  5.  2.  0.  2.  26.67  1.10  1. 


3.25  7.90 

6.17.2510.40  2.  0.00  0.00  0. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

0.00  0.00 

0.  0.00 

0.00  0.  0.00  0.00  0. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

12.  13.15. 

20.15.11 

.  0.11.  27.50  5.20  6, 

17.25  1.50 

3.  3.25 

1.60  4.17.25  0.70  5. 

3.25 

4.2011. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

0.00  0.00 

0.  0.00 

0.00  0.  0.00  0.00  0. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

13.  14.16. 

20.15.11 

.0.11.  30.00  2.50  9, 

3.25  1.70 

7.  3.25 

1.50  8.17.25  0.9010. 

3.25 

1.1011. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

0.00  0.00 

0.  0.00 

0.00  0.  0.00  0.00  0. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

14.  15.17. 

20.  5.11, 

.  0.11.  32.50  3.1012 

17.25  8.80 

6.17.25 

3.10  9.  3.25  2.1011. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

0.00  0.00 

0.  0.00 

0.00  0.  0.00  0.00  0. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

6. 

,100. 

9.: 

20. 

5. 

2. 

0.  2 

372.50  ; 

8.20 

1  3 

17, 

25  9 

.70 

2. 

0. 

00 

0 

.00 

0. 

,  0.00 

0 

.00 

0. 

0. 
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0. 

00 

0 
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0. 

,  0.00 

0 

.00 

0. 

0, 

.00 

0. 

.00 

0. 

0, 

.00 

0. 

,00 

0. 

0. 

,00 

0, 

,00 

0 

7. 

,101. 

10. 

20. 

.  5. 

2. 

0.  2 

375.00 

7.50 

1  4 

3. 

25  2 

.  10 

6. 

17. 

25 

2 

.50 

5. 

,  3.25 

8 

.70 

2. 

0. 

.00 

0, 

,00 

0. 

0, 

.00 

0. 

,00 

0. 

0. 

,00 

0. 

00 

0 

0. 

,00  0 

.00 

0. 

0. 

00 

0 

.00 

0. 

,  0.00 

0 

.00 

0. 

0, 

.00 

0, 

,00 

0. 

0. 

.00 

0. 

,00 

0. 

0. 

,00 

0. 

00 

0 

5. 

,  102. 

7. 

20. 

5. 

2. 

0.  2 

376.67 

1.10 

1  1 

3. 

,25  7 

.90 

6. 

17. 

,2510 

.40 

2. 

,  0.00 

0 

.00 

0. 

0, 

.00 

0. 

.00 

0. 

0. 

.00 

0, 

.00 

0. 

0, 

.00 

0. 

,00 

0 

0. 

,00  0 

.00 

0. 

0. 

,00 

0 

.00 

0. 

,  0.00 

0 

.00 

0. 

0. 

.00 

0. 

.00 

0. 

0. 

.00 

0. 

,00 

0. 

0. 

,00 

0, 

00 

0 

8, 

,103. 

11. 

7. 

15. 

,  9. 

0.  9 

377 . 50 

1.70 

1  7 

2. 

.25  2 

.30 

5. 

16. 

,25 

1 

.20 

4, 

.  2.25 

1 

.80 

3. 

16 

.25 

6, 

,20 

9. 

0, 

,00 

0, 

.00 

0. 

0, 

.00 

0. 

.00 

0 

0. 

,00  0 

.00 

0. 

0. 

,00 

0 

.00 

0. 

,  0.00 

0 

.00 

0. 

0. 

,00 

0, 

.00 

0. 

0, 

.00 

0. 

.00 

0. 

0. 

.00 

0. 

.00 

0 

9, 

,  104. 

12. 

7. 

15. 

,  9, 

0.  9 

O 

o 

o 

00 

CO 

0.60 

•  8 

2. 

,25  0 

.9010. 

2. 

,25 

0 

.80 

9. 

,  0.00 

0 

.00 

0. 

0, 

.00 

0. 

,00 

0. 

0, 

.00 

0. 

,00 

0. 

0. 

,00 

0. 

,00 

0 

0, 

,00  0 

.00 

0. 

0, 

.00 

0 

.00 

0, 

.  0.00 

0 

.00 

0. 

0 

,00 

0, 

.00 

0. 

0, 

,00 

0, 

,00 

0. 

0, 

,00 

0. 

.00 

0 

10, 

.  105. 

13. 

7. 

5. 

.  9. 

0.  9 

382.50 

0.5010 

2. 

,25  1 

.00 

8. 

2. 

,25 

0 

.50 

9. 

.  0.00 

0 

.00 

0. 

0. 

.00 

0, 

.00 

0. 

0, 

.00 

0. 

.00 

0. 

0, 

,00 

0. 

,00 

0 

0, 

,00  0 

.00 

0. 

0. 

,00 

0 

.00 

0. 

.  0.00 

0 

.00 

0. 

0. 

.00 

0, 

.00 

0. 

0, 

.00 

0. 

.00 

0. 

0, 

.00 

0. 

,00 

0 

11 , 

.  106. 

14. 

7. 

5, 

,  9, 

0.  9 

1 . 

385.00 

2.1011 

2, 

,25  5 

.20 

6 . 

16. 

,25 

1 

.80 

4 

.  2.25 

2 

.20 

7. 

16 

.25 

1, 

,50 

9. 

0, 

.00 

0. 

.00 

0. 

0, 

.00 

0. 

.00 

0 

0, 

,00  0 

.00 

0. 

0, 

.00 

0 

.00 

0, 

.  0.00 

0 

.00 

0. 

0, 

.00 

0. 

,00 

0. 

0, 

.00 

0, 

.00 

0. 

0, 

.00 

0. 

.00 

0 

12. 

,  107. 

15. 

20, 

,  15 

.11 

0.11 

387 . 50 

5.20 

1  6 

17, 

.25  1 

.50 

3. 

3 

.25 

1 

.60 

4 

.17.25 

0 

.70 

5. 

3 

.25 

4 

.2011. 

0 

.00 

0, 

.00 

0. 

0, 

.00 

0, 

.00 

0 

0, 
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0 

.00 

0, 
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0. 
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.00 

0, 

.00 

0. 

0 

.00 

0, 

,00 

0. 

0, 

.00 

0, 

.00 

0 

13, 

.  108. 

16. 

20 

.  15 

.11 

0.11 

390.00 

2.50 

1  9 

3. 

,25  1 

.70 

7. 

3, 

,25 

1 

.50 

8 

.17.25 

0 

.9010. 

3 

.25 

1 

.1011 . 

0, 

.00 

0, 

.00 

0. 

0, 

.00 

0. 

.00 

0 

0, 

.00  0 

.00 

0. 

0, 

.00 

0 

.00 

0 

.  0.00 

0 

.00 

0. 

0 

.00 

0 

.00 

0. 

0 

.00 

0, 

.00 

0. 

0 

.00 

0, 

.00 

0 

14 

.  109. 

17. 

20 

.  5 

.11 

0.11. 

392.50 

3.1012 

17, 

.25  8 

.80 

6. 

17, 

.25 

3 

.  10 

9 

.  3.25 

2 

. 1011. 
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.00 

0 

.00 

0. 
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.00 
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,00 

0. 
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.00  0 

.00 

0. 

0, 

.00 
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.00 

0, 

,  0.00 

0 

.00 

0. 

0 

.00 

0 

.00 

0. 

0 

.00 

0, 

.00 

0. 

0, 

,00 

0. 

,00 

0 

10.180.13. 

7. 

5.  9. 

,  0.  9.  670.50  0.5010 

o 

o 

8. 

2.25 

0.50  9.  0.00  0.00  0. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 

0.00  0.00 

0. 

0.00 

0.00  0.  0.00  0.00  0. 

0.00 

0.00 

0. 

0.00 

0.00 

0. 

0.00 

0.00 

0 
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11.181.14.  7.  5.  9.  0.  9.  673.00  2.1011. 

2.25  5.20  6.16.25  1.80  4.  2.25  2.20  7.16.25  1.50  9. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

5.182.  7.20.  5.  2.  0.  2.  676.67  1.10  1. 

3.25  7.90  6.17.2510.40  2.  0.00  0.00  0.  0.00  0.00  0. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

12.183.15.20.15.11.  0.11.  687.50  5.20  6. 

17.25  1.50  3.  3.25  1.60  4.17.25  0.70  5.  3.25  4.2011. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

13.184.16.20.15.11.  0.11.  690.00  2.50  9. 

3.25  1.70  7.  3.25  1.5C  8.17.25  0.9010.  3.25  1.1011. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

14.185.17.20.  5.11.  0.11.  692.50  3.1012. 

17.25  8.80  6.17.25  3.10  9.  3.25  2.1011.  0.00  0.00  0. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

5.186.  8.20.  5.  2.  0.  2.  693.33  1.10  1. 

3.25  7.90  6.17.2510.40  2.  0.00  0.00  0.  0.00  0.00  0. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

3.187.  4.50.  5.  1.  0.  1.  695.00  7.90  6. 

18.25  9.90  1.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

6.188.  9.20.  5.  2.  0.  2.  696.50  8.20  3. 

17.25  9.70  2.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 

5.189.  6.20.  5.  2.  0.  2.  710.00  1.10  1. 

3.25  7.90  6.17.2510.40  2.  0.00  0.00  0.  0.00  0.00  0. 

0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0.  0.00  0.00  0. 
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Appendix  R.  The  QUEUES. OUT  Output  File 


This  file  is  one  of  the  output  files  created  by  the  SLAM  cargo  route  simulation 
found  in  Appendices  D  and  E.  An  excerpt  of  the  file  created  from  the  hypothetical 
twelve- airport  route  system  follows: 


BEGIN 

END 

STOP 

PLANE 

ON 

DEPART 

NUMBER 

MEAN 

TOTAL 

PORT 

PORT 

AT 

NUMBER 

FLIGHT 

TIME 

OF 

DELAY 

DELAY 

1 

4 

1 

2 

191 

722.50 

16 

7.80 

124.80 

1 

4 

1 

2 

241 

902.50 

23 

7.80 

179.40 

1 

4 

1 

2 

286 

1082.50 

14 

7.80 

109.20 

1 

4 

1 

2 

335 

1262.50 

13 

7.80 

101.40 

SUBTOTAL  DELAY  FOR  CARGO  GOING  FROM  1  TO  4  AT  PORT  1  IS  514.80 
TOTAL  DELAY  FOR  CARGO  GOING  FROM  1  TO  4  IS  514.80 


BEGIN 

END 

STOP 

PLANE 

ON 

DEPART 

NUMBER 

MEAN 

TOTAL 

PORT 

PORT 

AT 

NUMBER 

FLIGHT 

TIME 

OF 

DELAY 

DELAY 

2 

3 

1 

1 

190 

720.00 

3 

7.90 

23.70 

2 

3 

1 

1 

214 

810.00 

5 

7.90 

39.50 

2 

3 

1 

1 

240 

900.00 

4 

7.90 

31.60 

2 

3 

1 

1 

263 

990.00 

5 

7.90 

39.50 

2 

3 

1 

1 

284 

1080.00 

5 

7.90 

39.50 

2 

3 

1 

1 

309 

1170.00 

4 

7.90 

31.60 

2 

3 

1 

1 

334 

1260.00 

7 

7.90 

55.30 

2 

3 

1 

1 

358 

1350.00 

1 

7.90 

7.90 

SUBTOTAL  DELAY  FOR 

CARGO  GOING  FROM 

1  2  TO 

3  AT  PORT  1 

IS  268 

2 

3 

2 

5 

164 

607.50 

3 

112.50 

337 . 5C 

2 

3 

2 

9 

195 

732.50 

7 

8.20 

57.40 

2 

3 

2 

9 

207 

768.50 

7 

8.20 

57.40 

2 

3 

2 

9 

211 

804.50 

7 

8.20 

57.40 

2 

3 

2 

5 

193 

727.50 

6 

97.50 

585.00 

2 

3 

2 

9 

224 

840.50 

12 

8.20 

98.40 

2 

3 

2 

9 

233 

876.50 

8 

8.20 

65.60 

2 

3 

2 

5 

227 

847.50 

7 

103.93 

727.50 

2 

3 

2 

9 

243 

912.50 

6 

8.20 

49.20 

2 

3 

2 

9 

252 

948.50 

8 

8.20 

65.60 

2 

3 

2 

9 

261 

984.50 

7 

8.20 

57.40 

2 

3 

2 

5 

259 

967.50 

6 

97.50 

585.00 

IM 


2 

3 

2 

9 

270 

1020.50 

8 

8.20 

65.60 

2 

3 

2 

9 

282 

1056.50 

8 

8.20 

65.60 

2 

3 

2 

9 

289 

1092.50 

8 

8.20 

65.60 

2 

3 

2 

9 

301 

1128.50 

13 

8.20 

106.60 

2 

3 

2 

9 

306 

.164.50 

7 

8.20 

57.40 

2 

3 

2 

5 

288 

1087.50 

4 

82.50 

330.00 

2 

3 

2 

9 

319 

1200.50 

7 

8.20 

57.40 

2 

3 

2 

9 

328 

1236.50 

8 

8.20 

65.60 

2 

3 

2 

5 

321 

1207.50 

7 

52.50 

367.50 

2 

3 

2 

9 

338 

1272.50 

7 

8.20 

57.40 

2 

3 

2 

9 

346 

1308.50 

13 

8.20 

106.60 

2 

2 

9 

355 

1344.50 

8 

8.20 

65.60 

2 

3 

2 

5 

353 

1327.50 

1 

22.50 

22.50 

2 

3 

2 

9 

365 

1380.50 

12 

8.20 

98.40 

SUBTOTAL 

DELAY 

FOR 

CARGO 

GOING  FROM  2  TO 

3  AT 

PORT  2 

IS  4275 

TOTAL  DELAY  FOR 

CARGO 

GOING 

FROM  2  TO 

3  IS 

4543.80 

BEGIN 

END 

STOP 

PLANE 

ON 

DEPART 

NUMBER 

MEAN 

TOTAL 

PORT 

PORT 

AT 

NUMBER 

FLIGHT 

TIME 

OF 

DELAY 

DELAY 

2 

12 

1 

1 

120 

450.00 

1 

26.15 

26.15 

2 

12 

1 

1 

190 

720.00 

1 

26.15 

26.15 

2 

12 

1 

1 

240 

900.00 

1 

26.15 

26.15 

2 

12 

1 

1 

145 

540.00 

1 

26.15 

26.15 

2 

12 

1 

1 

284 

1080.00 

3 

26.15 

78.45 

2 

12 

1 

1 

169 

630.00 

1 

26.15 

26.15 

SUBTOTAL  DELAY  FOR 

CARGO 

GOING  FROM 

2  TO 

12  AT  PORT  1 

IS  209 

2 

12 

2 

9 

117 

444 . 50 

3 

30.68 

92.05 

2 

12 

2 

10 

79 

285.00 

1 

10.75 

10.75 

2 

12 

2 

10 

101 

375.00 

1 

10.75 

10.75 

2 

12 

2 

9 

112 

408.50 

2 

13.00 

26.00 

2 

12 

2 

5 

99 

367.50 

1 

82.50 

82.50 

2 

12 

2 

10 

174 

645.00 

4 

10.75 

43.00 

2 

12 

2 

5 

164 

607.50 

2 

67.50 

135.00 

2 

12 

2 

9 

130 

480.50 

2 

33.60 

67.20 

2 

12 

2 

9 

139 

516.50 

3 

28.47 

85.40 

2 

12 

2 

10 

128 

465.00 

4 

10.75 

43.00 

2 

12 

2 

10 

245 

915.00 

3 

10.75 

32.25 

2 

12 

2 

5 

193 

727.50 

1 

172.50 

172.50 

2 

12 

2 

9 

252 

948.50 

1 

49.00 

49.00 

2 

12 

2 

9 

270 

1020.50 

1 

49.00 

49.00 

2 

12 

2 

9 

149 

552.50 

3 

22.95 

68.85 

2 

12 

2 

5 

132 

487 . 50 

1 

52.50 

52.50 

2 

12 

2 

9 

166 

624.50 

2 

30.20 

60.40 

2 

12 

2 

10 

290 

1095.00 

2 

10.75 

21.50 

2 

12 

2 

5 

259 

967.50 

3 

112.50 

337.50 

n  2 


2 

12 

2 

10 

150 

555.00 

4 

10.75 

43.00 

2 

12 

2 

10 

268 

1005.00 

3 

10.75 

32.25 

2 

12 

2 

9 

306 

1164.50 

2 

40.33 

80.65 

2 

12 

2 

9 

319 

1200.50 

1 

13.00 

13.00 

2 

12 

2 

9 

176 

660.50 

2 

51.60 

103.20 

2 

12 

2 

9 

188 

696.50 

3 

18.20 

54.60 

2 

12 

2 

9 

338 

1272.50 

1 

42.20 

42.20 

2 

12 

2 

9 

328 

1236.50 

1 

49.65 

49.65 

SUBTOTAL  DELAY 

FOR 

CARGO 

GOING  FROM  2  TO  12 

AT 

PORT  2 

IS  1857 

2 

12 

3 

15 

118 

474.70 

2 

18.85 

37.70 

2 

12 

3 

11 

103 

421.50 

2 

83.75 

167.50 

2 

12 

3 

1 

120 

476.15 

2 

59.10 

118.20 

2 

12 

3 

1 

190 

746.15 

1 

59.10 

59.10 

2 

12 

3 

15 

134 

534.70 

3 

18.85 

56.55 

2 

12 

3 

1 

240 

926.15 

1 

59.10 

59.10 

2 

12 

3 

11 

253 

997.50 

1 

35.50 

35.50 

2 

12 

3 

11 

119 

493.50 

1 

71.75 

71.75 

2 

12 

3 

11 

272 

1069.50 

1 

35.75 

35.75 

2 

12 

3 

11 

140 

565.50 

2 

35.50 

71.00 

2 

12 

3 

15 

152 

594.70 

1 

18.85 

18.85 

2 

12 

3 

1 

145 

566.15 

2 

69.60 

139.20 

2 

12 

3 

15 

168 

654.70 

2 

18.85 

37.70 

2 

12 

3 

1 

284 

1106.15 

3 

59.10 

177.30 

2 

12 

3 

1 

309 

1196.15 

1 

89.10 

89.10 

2 

12 

3 

11 

308 

1213.50 

2 

71.75 

143.50 

2 

12 

3 

15 

183 

714.70 

4 

18.85 

75.40 

2 

12 

3 

11 

178 

709.50 

1 

35.50 

35.50 

2 

12 

3 

1 

169 

656.15 

1 

88.85 

88.85 

2 

12 

3 

15 

341 

1314.70 

1 

18.85 

18.85 

2 

12 

3 

1 

334 

1286.15 

1 

59.10 

59.10 

SUBTOTAL  DELAY  FOR  CARGO  GOING  FROM  2  TO  12  AT  PORT  3  IS  1595.50 


2 

12 

4 

15 

118 

493.55 

2 

3.95 

7.90 

2 

12 

4 

10 

79 

295.75 

1 

203.15 

203.15 

2 

12 

4 

10 

101 

385.75 

1 

113.15 

113.15 

2 

12 

4 

10 

174 

655.75 

4 

143.15 

572.60 

2 

12 

4 

15 

134 

553.55 

3 

3.95 

11.85 

2 

12 

4 

10 

128 

475.75 

4 

83.15 

332.60 

2 

12 

4 

10 

245 

925.75 

3 

53.15 

159.45 

2 

12 

4 

15 

152 

613.55 

1 

3.95 

3.95 

2 

12 

4 

15 

168 

673.55 

2 

3.95 

7.90 

2 

12 

4 

10 

290 

1105.75 

2 

53.15 

106.30 

2 

12 

4 

10 

150 

565.75 

4 

143.15 

572.60 

2 

12 

4 

10 

268 

1015.75 

3 

303.15 

909.45 

2 

12 

4 

15 

183 

733 . 55 

4 

3.95 

15.80 

2 

12 

4 

15 

341 

1333.55 

1 

3.95 

3.95 

SUBTOTAL  DELAY  FOR  CARGO  GOING  FROM  2  TO  12  AT  PORT  4  IS  3020.65 


2 

12 

5 

15 

118 

497.50 

2 

255.00 

510.00 

2 

12 

5 

15 

134 

557.50 

3 

375.00 

1125.00 

2 

12 

5 

15 

152 

617.50 

1 

495.00 

495.00 

2 

12 

5 

15 

168 

677.50 

2 

435.00 

870.00 

2 

12 

5 

15 

183 

737.50 

4 

555.00 

2220.00 

2 

12 

5 

15 

341 

1337.50 

1 

15.00 

15.00 

SUBTOTAL  DELAY 

FOR 

CARGO 

GOING  FROM 

2  TO 

12 

AT 

PORT  5 

IS  5235 

2 

12 

6 

17 

123 

498.90 

2 

6.35 

12.70 

2 

12 

6 

17 

204 

798.90 

4 

6.35 

25.40 

2 

12 

6 

17 

137 

558.90 

4 

6.35 

25.40 

2 

12 

6 

17 

249 

978.90 

3 

6.35 

19.05 

2 

12 

6 

17 

298 

1158.90 

2 

6.35 

12.70 

2 

12 

6 

17 

171 

678.90 

2 

6.35 

12.70 

2 

12 

6 

17 

326 

1278.90 

1 

6.35 

6.35 

2 

12 

6 

17 

185 

738.90 

2 

6.35 

12.70 

2 

12 

6 

17 

343 

1338.90 

2 

6.35 

12.70 

SUBTOTAL  DELAY 

FOR 

CARGO 

GOING  FROM 

2  TO 

12 

AT 

PORT  6 

IS  139 

2 

12 

7 

16 

170 

640.70 

2 

18.75 

37.50 

SUBTOTAL 

.  DELAY 

FOR 

CARGO 

GOING  FROM 

2  TO 

12 

AT 

PORT  7 

IS  37 

2 

12 

8 

16 

170 

659.45 

2 

4.15 

8.30 

SUBTOTAL  DELAY 

FOR 

CARGO 

GOING  FROM 

2  TO 

12 

AT 

PORT  8 

IS  8 

2 

12 

9 

17 

123 

505.25 

5 

247.25 

1236.25 

2 

12 

9 

17 

204 

805.25 

5 

7.25 

36.25 

2 

12 

9 

17 

137 

565.25 

6 

407.25 

2443.50 

2 

12 

9 

17 

249 

985.25 

4 

7.25 

29.00 

2 

12 

9 

14 

276 

1033.00 

1 

19.50 

19.50 

2 

12 

9 

17 

280 

1105.25 

1 

7.25 

7.25 

2 

12 

9 

14 

162 

601.00 

2 

511.50 

1023.00 

2 

12 

9 

16 

170 

635.75 

2 

4.95 

9.90 

2 

12 

9 

17 

298 

1165.25 

5 

7.25 

36.25 

2 

12 

9 

17 

171 

685.25 

2 

547.25 

1094.50 

2 

12 

9 

17 

326 

1285.25 

4 

7.25 

29.00 

2 

12 

9 

14 

200 

745.00 

2 

547.50 

1095.00 

2 

12 

9 

17 

185 

745.25 

2 

547.25 

1094.50 

2 

12 

9 

17 

343 

1345.25 

3 

7.25 

21.75 

SUBTOTAL  DELAY 

FOR 

CARGO 

GOING  FROM 

2  TO 

12 

AT 

PORT  9 

IS  8175 

2 

12 

10 

16 

170 

663.60 

2 

448.90 

897.80 

SUBTOTAL  DELAY  FOR  CARGO  GOING  FROM  2  TO  12  AT  PORT  10  IS  897.80 


HI 


2 

12 

11 

17 

204 

752.50 

7 

3.10 

21.70 

2 

12 

11 

17 

217 

812.50 

5 

3.10 

15.50 

2 

12 

11 

17 

249 

932.50 

7 

3.10 

21.70 

2 

12 

11 

17 

265 

992.50 

4 

3.10 

12.40 

2 

12 

11 

17 

280 

1052.50 

3 

3.10 

9.30 

2 

12 

11 

17 

298 

1112.50 

8 

3.10 

24.80 

2 

12 

11 

17 

312 

1172.50 

5 

3.10 

15.50 

2 

12 

11 

17 

326 

1232.50 

2 

3.10 

6.20 

2 

12 

11 

17 

343 

1292.50 

12 

3.10 

37.20 

2 

12 

11 

17 

360 

1352.50 

4 

3.10 

12.40 

SUBTOTAL  DELAY  FOR 

CARGO 

GOING  FROM  2  TO 

12 

AT 

PORT  11  IS 

176 

TOTAL  DELAY  FOR 

CARGO 

GOING 

FROM  2  TO 

12 

IS 

21353.70 

TOTAL  DELAY  FOR  ALL  CARGO  IS  222647.22 


R  .') 


Appendix  S.  The  LEGS. OUT  Output  File 


This  file  is  one  of  the  output  files  created  by  the  SLAM  cargo  route  simulation 


found  in  Appendices  D  and  E.  An  excerpt  of  the  file  created  from  the  hypothetical 


twelve-airport  route  system  follows: 


FLIGHT 

TAIL 

MISSQN 

LEG 

CARGO 

CARGO  NUMBER 

TIME 

NUMBER 

NUMBER 

NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

190 

1 

1 

1 

1 

12 

26 

720.00 

190 

1 

1 

1 

1 

9 

20 

720.00 

190 

1 

1 

1 

2 

3 

3 

720.00 

190 

1 

1 

1 

2 

12 

1 

720.00 

190 

CAPACITY [50] 

1 

UNUSED: 

0 

190 

1 

1 

2 

1 

12 

26 

720.00 

190 

1 

1 

2 

1 

9 

20 

720.00 

190 

1 

1 

2 

2 

12 

1 

720.00 

190 

1 

1 

2 

2 

7 

1 

746.15 

190 

1 

1 

2 

2 

8 

1 

746.15 

190 

1 

1 

2 

2 

12 

1 

746.15 

190 

CAPACITY [50] 

2 

UNUSED: 

0 

190 

1 

1 

3 

8 

2 

6 

770.60 

190 

1 

1 

3 

9 

1 

8 

770.60 

190 

1 

1 

3 

7 

5 

1 

770.60 

190 

1 

1 

3 

8 

5 

2 

770.60 

190 

1 

1 

3 

10 

1 

1 

770.60 

190 

1 

1 

3 

10 

3 

1 

770.60 

190 

CAPACITY [50] 

3 

UNUSED: 

31 

190 

1 

1 

4 

8 

2 

6 

770.60 

190 

1 

1 

4 

9 

1 

8 

770.60 

190 

1 

1 

4 

10 

1 

1 

770.60 

190 

1 

1 

4 

10 

3 

1 

770.60 

190 

1 

1 

4 

5 

2 

3 

792.55 

190 

CAPACITY [50] 

4 

UNUSED: 

31 

FLIGHT 

TAIL 

MISSON 

LEG 

CARGO 

CARGO 

NUMBER 

TIME 

NUMBER 

NUMBER 

NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

191 

2 

2 

1 

1 

12 

14 

722.50 

191 

2 

2 

1 

1 

9 

11 

722.50 

191 

2 

2 

1 

1 

4 

16 

722.50 

191 

2 

2 

1 

6 

4 

6 

722.50 

191 

2 

2 

1 

9 

4 

1 

722.50 

SI 


191 

2 

2 

1 

8 

4 

1 

722.50 

191 

2 

2 

1 

5 

4 

1 

722.50 

191 

CAPACITY[50] 

1 

UNUSED : 

0 

191 

2 

2 

2 

1 

12 

14 

722.50 

191 

2 

2 

2 

1 

9 

11 

722.50 

191 

CAPACITY [50] 

2 

UNUSED ; 

25 

191 

2 

2 

3 

10 

4 

2 

770.80 

191 

2 

2 

3 

8 

4 

1 

770.80 

191 

2 

2 

3 

9 

4 

1 

770.80 

191 

CAPACITY [50] 

3 

UNUSED : 

46 

191 

2 

2 

4 

4 

1 

12 

793.35 

191 

CAPACITY [50] 

4 

UNUSED: 

38 

FLIGHT 

TAIL 

MISSON 

LEG 

CARGO 

CARGO  NUMBER 

TIME 

NUMBER 

NUMBER  NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

192 

3 

3 

1 

1 

6 

50 

725.00 

192 

CAPACITY [50] 

1 

UNUSED : 

0 

192 

3 

3 

2 

6 

1 

27 

751.15 

192 

3 

3 

2 

6 

4 

1 

751.15 

192 

CAPACITY  [50] 

2 

UNUSED: 

22 

FLIGHT 

TAIL 

MISSON 

LEG 

CARGO 

CARGO  NUMBER 

TIME 

NUMBER 

NUMBER 

NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

193 

5 

4 

1 

2 

3 

6 

727.50 

193 

5 

4 

1 

2 

7 

3 

727.50 

193 

5 

4 

1 

2 

8 

4 

727.50 

193 

5 

4 

1 

2 

5 

5 

727.50 

193 

5 

4 

1 

2 

12 

2 

727.50 

193 

CAPACITY [20] 

1 

UNUSED: 

0 

193 

5 

4 

2 

8 

2 

12 

731.85 

193 

5 

4 

2 

7 

2 

4 

731.85 

193 

5 

4 

2 

5 

2 

4 

731.85 

193 

CA.^ACITY[20] 

2 

UNUSED : 

0 

FLIGHT 

TAIL 

MISSON 

LEG 

CARGO 

CARGO 

NUMBER 

TIME 

NUMBER 

NUMBER 

NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

194 

6 

5 

1 

6 

1 

19 

730.00 

194 

6 

5 

1 

10 

1 

1 

730.00 

194 

CAPACITY [20] 

1 

UNUSED 

:  0 

S-2 


194 

6 

5 

2 

1 

6 

13 

734.35 

194 

6 

5 

2 

2 

7 

3 

734.35 

194 

6 

5 

2 

2 

8 

4 

734.35 

194 

CAPACITY [20] 

2 

UNUSED : 

0 

194 

6 

5 

3 

6 

1 

14 

759.50 

194 

6 

5 

3 

10 

1 

2 

759.50 

194 

CAPACITY [20] 

3 

UNUSED : 

4 

FLIGHT 

TAIL 

MISSON 

LEG 

CARGO 

CARGO  NUMBER 

TIME 

NUMBER 

NUMBER 

NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

195 

9 

6 

1 

2 

12 

3 

732.50 

195 

9 

6 

1 

2 

3 

7 

732.50 

195 

9 

6 

1 

2 

8 

5 

732.50 

195 

9 

6 

1 

2 

7 

4 

732.50 

195 

9 

6 

1 

2 

10 

1 

732.50 

195 

CAPACITY [20] 

1 

UNUSED 

:  0 

195 

9 

6 

2 

3 

2 

11 

757.95 

195 

CAPACITY [20] 

2 

UNUSED 

:  9 

FLIGHT 

TAIL 

MISSON 

LEG 

CARGO 

CARGO  NUMBER 

TIME 

NUMBER 

NUMBER 

NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

196 

10 

7 

1 

2 

8 

7 

735.00 

196 

10 

7 

1 

2 

12 

4 

735.00 

196 

10 

7 

1 

2 

7 

3 

735.00 

196 

10 

7 

1 

2 

5 

5 

735.00 

196 

10 

7 

1 

2 

10 

1 

735.00 

196 

CAPACITY [20] 

1 

UNUSED: 

0 

196 

10 

7 

2 

2 

8 

7 

735.00 

196 

10 

7 

2 

2 

12 

4 

735.00 

196 

10 

7 

2 

2 

7 

3 

735.00 

196 

10 

7 

2 

2 

10 

1 

735.00 

196 

10 

7 

2 

3 

6 

5 

745.75 

196 

CAPACITY [20] 

2 

UNUSED: 

0 

196 

10 

7 

3 

12 

5 

1 

765.10 

196 

10 

7 

3 

2 

5 

1 

765.10 

196 

CAPACITY [20] 

3 

UNUSED: 

18 

196 

10 

7 

4 

5 

2 

6 

770.85 

196 

10 

7 

4 

7 

2 

4 

770.85 

196 

CAPACITY [20] 

4 

UNUSED : 

10 

FLIGHT 

TAIL 

MISSON 

LEG 

CARGO 

CARGO  NUMBER 

TIME 

S-3 


NUMBER 

NUMBER  NUMBER 

NUMBER 

ORIG 

DEST 

OF 

GOT  ON 

197 

11 

8 

1 

8 

7 

1 

737.50 

197 

11 

8 

1 

2 

7 

5 

737.50 

197 

11 

8 

1 

7 

5 

1 

737.50 

197 

CAPACITY [ 

7] 

1 

UNUSED : 

0 

197 

11 

8 

2 

7 

5 

1 

737.50 

197 

11 

8 

2 

7 

2 

4 

741.45 

197 

11 

8 

2 

7 

5 

2 

741.45 

197 

CAPACITY C 

7] 

2 

UNUSED : 

0 

197 

11 

8 

3 

5 
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